Re: Possible improvements to the LNUM patch?

[Doug Currie <doug.currie@...>]

On Tuesday, April 15, 2008 Aladdin Lampé wrote: 

> Indeed, the calculations (Lua scripts) are provided by the users of
> my application, and I don't feel like explaining in the
> documentation that it is forbidden to test whether 1 <
> decNumber.tonumber("1.5") and that what they should write instead
> is: decNumber.tonumber("1") < decNumber.tonumber("1.5")...
>  
> That's why I'm thinking of integrating the ldecnumber module into
> the LNUM patch. What do you guys think about that?
> I think that this would be a really great addition to the Lua
> language, offering to Lua all the power of arbitrary precision
> maths, without the previous side effects and without the added
> comlexity each time tou deal with numbers (decNumber.tonumber stuff, etc.)

Your arguments are compelling from a user standpoint. 

The inability for userdata libraries to coerce Lua numbers in
comparison operations in Lua 5.1.x is perhaps my biggest
disappointment in ldecNumber. [It would also be nice to extend the
lexer to read decNumbers directly, but that can be mitigated with a
short function name aliasing decNumber.tonumber, and I don't want to
start a syntactic transformation thread!]

Since all of these approaches require patching Lua, I have resisted 
them. I cannot afford the maintenance commitment.

If you want to take on that commitment, I have a few suggestions:

- consider simply patching Lua to support coercion in the comparison 
operators; this is a smaller change, is applicable to libraries in 
addition to ldecNumber, and maybe stands a chance of being 
incorporated into a future official Lua release (though it's not on 
http://lua-users.org/wiki/LuaFiveTwo yet!)

- barring that, consider incorporating it into "official" LNUM with 
Asko's support; this will increase the LNUM user base and share the 
maintenance work as each new version of Lua is released; of course it 
will also increase the complexity of LNUM and the maintenance job; 
this also provides a mechanism to support both decNumbers and Lua 
numbers simultaneously

- although arbitrary precision is great, consider decNumber's new 
fixed size options; since my last release of ldecNumber, IBM have 
released a version of decNumber with decDouble (64 bit) and decQuad 
(128 bit) types; these are faster than arbitrary precision, and easier 
on the memory allocator; I have intentions to add these types to 
ldecNumber, but have not done so yet

Have fun!

-- e

-- 
Doug Currie
Londonderry, NH, USA