Re: Possible improvements to the LNUM patch?

[Asko Kauppi <askok@...>]

Adding limited DEC support to LNUM would not be a very big endeavour,  
actually.

Unlike the original idea (1-2 years back) to do all Lua numbers using  
fixed point arithmetic, DEC mode could simply use the existing integer  
optimization, and concern mostly at input/output of numbers (heck, I'm  
forgetting about * / and % here!). And fallback conversion to float  
should take the DEC factor into account. Anyways, these would be in  
the magnitude of 100 lines, not more.

This would essentially provide a Lua, where writing 1.234 would be a  
DEC number whereas 1.2345677 would be floating point (depending on the  
number of fixed digits selected, of course). Should be enough for  
financial applications, I guess (especially with 64-bit ints). And no  
dependencies to external libraries required.

-asko


Doug Currie kirjoitti 15.4.2008 kello 18:13:
> 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