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.

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

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.

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.

[Please log in to post a comment]