Re: Lua number type and 64-bit machines

[askok@...]

As to the file offsets, double's 53 bits of mantissa 
should suffice.  Gives one 8192TB if I wasn't mistaken.

The situation seems that Lua authors are aware of the 
potential need, but there is no real case that couldn't be 
handled with this and lightuserdata (as someone noted). If 
you do have a genuine 64-bit need (i.e. because of some 
API you need to use), LNUM patch does this as Steve 
already noted. Or you can just wrap those 64-bit values as 
userdata in your C module/binding.

- asko


On Thu, 5 Mar 2009 21:49:29 -0800
 John Barham <jbarham@gmail.com> wrote:
> Hi all, Lua newbie (but long-time C and Python 
> programmer) here, and
> apologies if this issue has already been resolved.
>
> Given the following:
>
> 1. Lua's number type is conventionally a typedef for 
> 64-bit double
> precision floating-point numbers
> 2. 64-bit floats can only represent integers up to 53 
> bits of precision
> 3. 64-bit machines are becoming increasingly popular
>
> is there a case for adding a separate integer numeric 
> type to Lua?  Or
> would it be feasible to emulate Python's arbitrary 
> precision "long"
> integer type that is automatically created on overflow?
>
> I appreciate that currently having only one numeric type 
> helps keep
> Lua simple, but I fear that on 64-bit machines Lua's 
> number type might
> not be able to represent common integer values such as 
> process ids or
> file offsets.
>
>  John