Re: At the edge of LNUM patch

[Mark Hamburg <mhamburg@...>]

on 3/25/08 1:50 PM, Asko Kauppi at askok@dnainternet.net wrote:

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

Sorry. I wrote too fast. My point was that even 2 ^ 63 - 1 should be stored
as a double.

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

I would forego the extra precision in order to exactly preserve the
unpatched semantics.

>> 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?

The examples in this thread show that it isn't. If I can keep extra integer
precision beyond what a purely double-based version would give me, then I
can detect that the patch has been applied.

Mark