Log In  1  In PICO-8, the % operator causes numbers to wrap like this:

 ```print(-1 % 10) -- 9 print(0 % 10) -- 0 print(1 % 10) -- 1```

As I understand it, to compute x % y, you take x and add/subtract y from it, making it bigger if it's negative and smaller if it's too big, until x >= 0 and x < y. As long as y is not zero, the result should always be positive.

Well, -32768 % y is negative for some values of y:

 `print(-32768 % 20000) -- negative result: -12768`

After trying a bunch of values for y, the rules look... complicated:

• If -0x4000 <= y and y <= 0x4000, then x % y is positive 32768 minus abs(y) a bunch of times, until it's in the proper range.
• If y < -0x4000 or 0x4000 > y, then x % y is -32768 plus abs(y) multiple times, but not enough times to make the number non-negative.

Is this a bug? This doesn't seem like intended (or useful) behavior to me.

P#67473 2019-09-10 05:38

:: dw817  Positive and negative can be quite tricky,cmounce. For instance, in a program I wrote recently I found that I was receiving a negative number for counting too high.

I wanted to make sure a number was from zero to 32767 and no higher.

For instance, try this code:

 ```p=32760 cls() for i=1,10 do print(p) p=p+rnd()*2+1 end ```

You can see the result gets "too high" and reverts to a negative number. You would think this would be the solution, but no.

 ```p=32760 cls() for i=1,10 do print(p) p=p+rnd()*2+1 if (p>32767) p=32767 end ```

But no, that doesn't work. So - how to fix this ?

Well since I only need numbers from 0 to 32767 you can do the following.

 ```p=32760 cls() for i=1,10 do print(p) p=p+rnd()*2+1 if (p<0) p=32767 end ```

Which strangely works. So, yeah, once you get up to 32767 the numbers go all wonky.

Would be nice in PICO to have a LONGINT so you can have:

-4294967296 to 4294967295

P#67484 2019-09-10 17:47 ( Edited 2019-09-10 17:50)  Yes, dw817, what you're saying makes sense for addition. When you go outside of PICO-8's range on the positive side, you wrap around to the negative side, because that's just how two's complement arithmetic works.

However, I'm talking about something different: I'm talking about the modulo operator, and I'm talking about an operation where the numbers never exceed the range of PICO-8's numeric type:

• -32768 is in range, per the manual: "[Numbers] range from -32768.0 to 32767.99999"
• 20000 is also in range.
• Expected value of -32768 % 20000: Add 20000 to get -12768. Add 20000 to get the final answer, 7232. At no time does a number ever exceed PICO-8's range.
• Actual value of -32768 % 20000: -12768.
P#67502 2019-09-10 21:46
:: dw817  You are referring to 32767 and -32768. I suspect once you reach this range a lot of functions may not work correctly around it. For when you wrap from that number to negative, likely a whole bunch of stuff stops working properly.

I think you can fix your problem with a tweak. Remember when I found Pico could not do this statement correctly ?

 ``` if (ch="(") x-=1 ```

It's because the ( is on the same line.

Let's see ... a tweak I think to fix what you're doing above:

 ```cls() a=-32768 b=20000 r=abs(a)%b*sgn(a) print(r) ```

This gets the correct result.

P#67507 2019-09-10 22:09  "It's because the ( is on the same line."

I presume you bring that up to say that PICO-8 has many bugs, and we should just work around them. :-)

P#67514 2019-09-11 00:14
:: dw817  Yep. Almighty ZEP will eventually get around to all of 'em. Gotta admit, PICO-8 is pretty great even with its problems.

There should always be some kind of way to work around problems ...

P#67515 2019-09-11 00:36