lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Mark Hamburg kirjoitti 25.3.2008 kello 18:36:
The patch should kick out of the integer realm at the boundary of
floating-point precision not at the boundary of integer precision. Thus, calculating 2 ^ 63 should result in the value being stored as a double even
though it could fit into a 64-bit integer.

But this is exactly what it does. The "integer realm" is signed integers, -2^63 .. +2^63-1 with int64 mode. 2^63 does not fit into a signed 64-bit integer.

One minor note for people who may feel threatened by this patch; with default (double + int32) setup, FP accuracy exceeds integer accuracy and any behaviour is exactly like it's been on unpatched Lua.

This still gets you a lot more integer precision than a lot of code is used
to working with since 32-bit integers are more or less the norm.

Yes. Despite using signed range, one can actually store full hex 64- bit values (0..0xffffffffffffffff) in 64-bit mode. As long as no arithmetics happen on these values, and output is done using string.format('%x').

If one were to make this change, then I think it would achieve the property
that Lua's execution would be indistinguishable whether the patch was
installed or not which I think would be a good thing.

Maybe it's been this way all along?