RE: Numeric types, overhead and precision loss

["Grellier, Thierry" <t-grellier@...>]

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

-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br] On Behalf Of David Kastrup
Sent: Monday, May 21, 2007 2:19 PM
To: lua@bazar2.conectiva.com.br
Subject: Re: Numeric types, overhead and precision loss

"Grellier, Thierry" <t-grellier@ti.com> writes:

> Well adding a new type is quite some work, but doesn't bring such a
huge
> 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
> http://lua-users.org/wiki/LuaPowerPatches)
> - adding a hex type to lua
> (http://lua-users.lua.org/lists/lua-l/2006-11/msg00430.html). This
patch
> only adds an unsigned integer type and integer division, but at least
it
> 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
integer
> 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