lua-users home
lua-l archive

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

if you need 64 bits int (well > 53 bits).

-----Original Message-----
[] On Behalf Of David Kastrup
Sent: Monday, May 21, 2007 2:19 PM
Subject: Re: Numeric types, overhead and precision loss

"Grellier, Thierry" <> writes:

> Well adding a new type is quite some work, but doesn't bring such a
> overhead in the lua interpreter (maybe 4% code size).
> There are also 2 patches of interest:
> - asko's Integer optimization (non-FPU) patch, revised to Lua 5.1.1,
> which use an hybrid representation for lua number, staying int as long
> as result is int, but without adding new operators such as bitwise
> operators or integer division. (in
> - adding a hex type to lua
> ( This
> only adds an unsigned integer type and integer division, but at least
> shows where are all the changes to do when you want to introduce a new
> type, although it doesn't allow using this new type in a numeric for
> loop.
> For me, the most difficult when porting code is to be careful at
> division which can lead to inaccuracy when not properly translated.
> I wish that one day these two patches could be somehow merged and
> integrated into the lua language itself.

I am afraid that I am in the ranks of those who fail to see the
utility.  And that's even though I would want to do tasks like
translating a string char by char using a lookup table of integers,
and get, say, an array of 32-bit integers.

But I don't see that a self-extending hybrid integer/float number type
would do anything to reduce the required complexity.

David Kastrup