[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Possible improvements to the LNUM patch?
- From: Asko Kauppi <askok@...>
- Date: Tue, 15 Apr 2008 22:30:47 +0300
Adding limited DEC support to LNUM would not be a very big endeavour,
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
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
- 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
- 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
Londonderry, NH, USA