lua-users home
lua-l archive

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

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