In a normal Lua REPL, the following statement will evaluate to true:
print(string.sub('-24',0, 3)*1000) == -24000
In Pico-8, however, this operation causes a really tiny rounding error that was invisible even when printing the value.
Pico-8 should probably coerce the string into a number without a rounding error. And perhaps print() and printh() could also display all of the numbers to the right of the decimal if you pass it a floating point value? That would have helped a lot.
I didn't know you could do true commands in the command line ? Thought it had just a limited vocabulary for filing and SPLORE. Thanks for that ! Will help in debugging.
If you're talking fractions, many MANY game making languages always seem to duff it. I only got accurate REAL numbers from two languages I worked with and that was GWBasic and QBasic.
Not GFA, BlitzMAX, Delphi Noetic F-Basic, or even Turbo Pascal.
They are all off by a little bit when you start to hedge numbers on the verge of converting them to an integer.
Yeah I probably wouldn't call it a bug if I was dealing with some kind of fractional value. Precision loss is expected. Except seeing as how -24 is an integer that exists well within the range of PICO-8's supported numbers, I don't think it should lose precision when being coerced.
But maybe there's a good reason for this I'm unaware of?
[Please log in to post a comment]