lua-users home
lua-l archive

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

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.


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 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