I've been testing Pulp's integers and they appear to be signed 32 bits. This means the integer range is `-2147483648`

(minimum) to `2147483647`

(maximum).

So if you're trying to encode data in an integer to have no risk of overflow you should use no more than **10** digits for binary or **9** digits for base-10.

Wanted to share since I didn't see it documented anywhere

1 Like

Interestingly, the known modulo strategy breaks far below the integer upper bound

Given `y = 10`

, it seems to work on `x = 41943058`

and break on `x = 41943059`

. Tested with Playdate Simulator.

This seems like a bug with `/=`

or `floor`

. I'm not confident on which because for *both* `41943058`

and `41943059`

the log output of `/=`

appears as `4194306.0`

(which seems incorrect) but the `floor`

is correct on `41943058`

only. I suppose `floor`

seems more likely.

As far as I'm aware, encoding data in an integer is not feasible without modulo as it's serves as the read mechanism. Factoring this in reduces the numbers in my previous statement to **8** and **7** digits.

PDX zip file: Modulo-Testing_20230204215727.zip (32.5 KB)

Logs:

```
mod: 41943058
x: 41943058
y: 10
mod /= y
mod: 4194306.0
floor_mod = floor mod
floor_mod: 4194305
mod -= floor_mod
mod: 0.5
mod *= y
mod: 5.0
round_mod = round mod
round_mod: 5
mod = round_mod
mod: 5
---
mod: 41943059
x: 41943059
y: 10
mod /= y
mod: 4194306.0
floor_mod = floor mod
floor_mod: 4194306
mod -= floor_mod
mod: 0.0
mod *= y
mod: 0.0
round_mod = round mod
round_mod: 0
mod = round_mod
mod: 0
```