When does -1 not equal -1? When -1 started out as the string "-1", of course!

Please examine this source code closely, then run it for a surprise fixed point math bug or sommat.
(If you are visiting this thread in the future, after zep has updated the web player, refer to the cartridge label for the original output.)

(I do not know if this is a duplicate symptom of another bug that has already been fixed in 0.1.11, sorry...)

 ```-- start with a string. local m = "-1" -- m is a string. if m == "-1" then print("m is a string -1, to start") end -- coerce m into being a number. m = m*1 -- this is one method. m = m+0 -- this is another way. m = m/1 -- i guess you could do this too, but you probably shouldn't. -- why don't you just add tonumber() already. print([[m has been coerced into a number (but there's no way to be sure)]]) if m == -1 then -- this should be true. -- it would mean m is an -- ordinary number, valued -- at -1. print("m == -1") elseif m == "-1" then -- if coercion failed, -- then *this* should be true. print('m == "-1"') elseif m < 0 then -- neither of those are true, -- but m is still < 0 somehow?? print("m < 0, but not equal to -1") print("m prints as ["..m.."]") else -- wtf is m? print("???") end print(m.." + 1 is "..(m+1)) m = flr(m) if (m == -1) print("oh *now* it's -1. thanks flr.") ```

Cart #41419 | 2017-06-09 | Code ▽ | License: CC4-BY-NC-SA

Well, at least in the process of making this test cart I stumbled upon the workaround for it. flr("-1") is fine.

P#41420 2017-06-08 22:38 ( Edited 2017-06-09 21:21)

it seems negative numbers get an extra bit:
"-1"+0 == 0xFFFF.0001

P#41437 2017-06-09 09:04 ( Edited 2017-06-09 13:05)
:: zep

Wow, thanks for this -- fixed for 0.1.11

P#41500 2017-06-09 17:21 ( Edited 2017-06-09 21:22)