a=100 m1="-2"+0 m2=-2 print(m1) --- prints -2 print(a*m1) --- prints -199.998 print(a*m2) --- prints -200 |
While m1 prints as -2, a*m1 seems to be -199.998. Multiplying by m2, the exact same number but not parsed from string, doesn't have this problem and gives the correct answer: -200.
Maybe it's some sort of an off-by-one problem in the parsing that "-2"+0 implicitly does?
Anyway, would be great if this could be fixed for 0.1.9 :).


PICO-8 is entirely capable of holding -2.0 in a variable perfectly. I'm guessing it's a bug in the atof()-style parser...
Yeah, I just did the same test with a routine I use to print the exact contents of lua values in hex. Here's the result:

Definitely a bug. Good find.


It's also interesting that this erroneous 0xfffe.0001 still prints as "-2". I suppose this is also a bug, since numbers with different internal representations print the same, and only side effects can show you they're different - unless there is some internal max precision when printing?


I'm pretty sure it's set to show, like, 3 or 4 decimal digits, max. With 16-bit fractional precision, I suspect a lot of fractional numbers aren't quite what they get rounded off to when displayed. When you ask for 1.3, I'm betting that can't actually be encoded perfectly, but the rounding off in the print function saves you some headaches. Most of the time that's probably a good thing.


Try this one:
> a="-1" > a=a+0 > print(a) -1 > if a==-1 then print(12) end -- no output > if a=="-1" then print (12) end -- no output -- if the above is not enough > b=5+a > print(b) 4 > if b==4 then print(12) end -- no output > if b=="4" then print (12) end -- no output |
Aaaaaack! I wasted about 8 hours narrowing this down trying to figure out why my animations wouldn't run the same with data parsed from a string instead of hard coded. Next, I get to figure out what the heck to do about it.


The workaround appears to be:
> a="-1" > a=flr(a) |


Yeah, I'm well aware of rounding behaviors with negatives. It appears all negative conversions come in .0000262 too high. Thus, flr() works so far for both positive and negative to-number conversion.
I more want to know when and if this ever will be fixed. This is a pretty painful flaw in the language and greatly adds to my dislike of P8 Lua.


I put in a bug report on this long ago...
It doesn't always get it wrong:

I think it only messes up when the conversion is exact.
Something like this might be a good workaround:
function stofp(s) if sub(s,1,1)=="-" then return -(sub(s,2,#s)+0) else return s+0 end end |


Fixed in 0.1.12?
https://www.lexaloffle.com/bbs/?pid=63583
API Changes
API changes that required a cart version bump:
- divide and abs sign flipping for 0x8000.0000
- sqrt(0x0000.0001) freezes
- "-1"+0 evaluates to 0xffff.0001
[Please log in to post a comment]