1

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.

P#27954 2016-09-03 02:26 ( Edited 2016-09-03 18:46)

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.

P#27965 2016-09-03 12:15 ( Edited 2016-09-03 16:15)

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?

P#27968 2016-09-03 12:34 ( Edited 2016-09-03 16:34)

Did a little bit of testing myself, found this:

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

P#27969 2016-09-03 12:37 ( Edited 2016-09-03 18:48)

The joys of floating point numbers?

 >PRINT(-0X17.ffff==-24) FALSE >PRINT(FLR(-0X17.ffff)==-24) TRUE >
P#27977 2016-09-03 14:46 ( Edited 2016-09-03 18:46)