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]