[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua number type and 64-bit machines
- From: askok@...
- Date: Fri, 06 Mar 2009 11:12:35 +0200
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.
On Thu, 5 Mar 2009 21:49:29 -0800
John Barham <firstname.lastname@example.org> 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
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
integer type that is automatically created on overflow?
I appreciate that currently having only one numeric type
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