Log In  

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 :).

P#24746 2016-07-06 19:07 ( Edited 2016-11-18 12:59)

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.

P#24757 2016-07-06 20:53 ( Edited 2016-07-07 00:55)

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?

P#24809 2016-07-07 06:29 ( Edited 2016-07-07 10:29)

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.

P#24810 2016-07-07 06:36 ( Edited 2016-07-07 10:36)

True, if you're not able to influence the precision manually with a format string or somesuch, dropping after 3 decimals seems like a sane idea. That part is a non-issue then.

P#24846 2016-07-07 16:36 ( Edited 2016-07-07 20:36)

Honestly, I'd rather there be enough precision to show the minimum fractional value, for ease of diagnosing exactly this kind of problem. I've run into similar before (as a bug in my own code, not in PICO-8).

P#24849 2016-07-07 17:16 ( Edited 2016-07-07 21:16)

Do numbers in Pico-8 have some kind of special format? Is it just a standard 16-bit floating point number with 4 digits of accuracy, or something else?

P#24854 2016-07-07 19:28 ( Edited 2016-07-07 23:28)

@Danjen: They're signed 16.16 fixed point, range: [-32768.0, 32767.99999] or [0x8000.0000, 0x7fff.ffff]

P#24858 2016-07-07 20:38 ( Edited 2016-07-08 00:41)

Try this one:

> a="-1"
> a=a+0
> print(a)
> 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)
> 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.

P#32530 2016-11-15 20:13 ( Edited 2016-11-16 01:13)

The workaround appears to be:

> a="-1"
> a=flr(a)
P#32532 2016-11-15 20:43 ( Edited 2016-11-16 01:43)

Be careful with flr() and negative decimals. That might make a==-2

edit: though I assume that was probably the goal in this case

P#32542 2016-11-16 01:39 ( Edited 2016-11-16 06:41)

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.

P#32545 2016-11-16 02:40 ( Edited 2016-11-16 07:40)

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)
  return s+0
P#32602 2016-11-18 07:59 ( Edited 2016-11-18 12:59)

Thanks, I adapted it a little for my project:

function string_tonum(val)
  if sub(val, 1, 1) == '-' then
    return - tonum(sub(val, 2))
    return tonum(val)

(sub(s, n) will get the substring from n to the last character, so there is no need to pass #s)

P#61079 2019-01-22 00:43

Fixed in 0.1.12?


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
P#63704 2019-04-19 21:57

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2023-03-20 12:13:15 | 0.013s | Q:31