<div dir="ltr"><div>I was able to duplicate basically all reported math issues. I am noticing some slight discrepancies between JW Lua and the production release of RGP Lua, even though both are Lua 5.2. I suspect JW Lua is using an earlier iteration of Lua 5.2 than RGP Lua is. There also could be a difference between the Win and Mac compilations of Lua or the C compiler Jari used vs. the one I'm using.<br></div><div><br></div><div>The biggest find in all of this has to do with `math.pow`. The `pow` function is deprecated as of Lua 5.3 in favor of the ^ operator. However, there is a compiler flag to include the deprecated math functions, and I have now enabled that flag in the interest of maintaining maximum backward compatibility. Kudos to Jan for finding it.</div><div><br></div><div>The `tonumber` function only complains about non-string arguments if you specify a base. Since you are specifying base 10, which is the default, you could omit the base and then the error would not occur. That is:</div><div><br></div><div>tonumber(12) -- no error</div><div>tonumber(12, 10) -- error</div><div><br></div><div>I haven't found any compiler switch to address this, and it actually looks to me like it could be a bug. I can't see any motivation for treating one as an error but not the other. Nor can I find any documentation declaring the change as intentional.</div><div><br></div><div>Also, there doesn't appear to be any way to assign 1/0 (or 0/0) to an integer on Lua 5.4. Considering that on Lua 5.2 it ended up as -1, that's probably actually a benefit.<br></div><div><br></div><div>The Lua 5.4 behavior of entering the nan loop seems more correct to me than Lua 5.2 not entering it.</div><div><br></div><div>Let me know if any of these are showstoppers for anyone. While it is easy to go back, I am leaning more towards upgrading to 5.4 with the next release. But that release is not imminent, and there is plenty of room for more regression testing with it.</div><div><br></div><div>Robert</div><div><br></div><div><br></div></div>