RE: Numeric types, overhead and precision loss

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

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.

-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br] On Behalf Of Ralph Hempel
Sent: Friday, May 18, 2007 4:39 PM
To: Lua list
Subject: Re: Numeric types, overhead and precision loss

Gavin Wraith wrote:

> Ralph might be interested in looking at the sources for RiscLua, where
> arithmetic modulo 2^32 and bitwise operations are needed for system
calls.
> The CPU (various ARMs) generally have no fp. Doubles are implemented
with
> userdata.

I might indeed! I am currently following the basic principle of

   "Make it work, then make it fast"

I added bitwise operations with explicit functions like band(), bor()
etc, but I've looked at the integer patch for ideas too.

One of my main goals is to use as much 5.1.x source unaltered. The
reason for this is my experience with Forth. By the end of its useful
life, Forth had so many variants that the idea of portability
went right out the window.

I can live with having one API vs another, but when fundamental
language implementation differs too much between variants, the
result can be that the user base is spread so thin that the language
simply dies.

I will, however, go over the RiscLua source to see if there are
some ideas I can use, specifically with respect to userdata and the
alternative number type.

Cheers, Ralph