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?

Did a little bit of testing myself, found this:

EDIT: Also to note, numbers in PICO-8 are fixed point not floating point

The joys of floating point numbers?

>PRINT(-0X17.ffff==-24)
FALSE
>PRINT(FLR(-0X17.ffff)==-24)
TRUE
>