[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: LUA4.0 : Bug with maths
- From: "paulmatthews" <paulmatthews@<a href="/cgi-bin/echo.cgi?yahoo.com">...</a>>
- Date: Tue, 12 Feb 2002 02:42:39 -0000
--- In lua-l@y..., Luiz Henrique de Figueiredo <lhf@t...> wrote:
> Anyway, I don't think NAN, INF and other IEEE stuff are a
> requirement of ANSI C strtod. So, there's nothing we can do
> in tonumber in the general case (and nothing to do in the
> special cases when strtod does handle NAN!).
There is deeper problem here, and that is how LUA handles <, >, <=,
>=, == and ~=, and that problem is not the reliance on a single
comparison operator, but possibly the reliance on the wrong
comparison operator. Instead of 'lt' it should use 'cmp' where 'cmp'
should return -1,0,1 or nil (for nan or nil comparisons). The other
operators can all be determined from this one.
r = cmp(a,b);
if r == nil then
The other alternative is not to derive one ordering from relation
from the other. If the code says >= there must be a 'ge' tag to tell
how its done. If the code says > there must be a 'gt' tag to tell it
how its done.
No offence, but I think you might be confusing the operation of your
particular machine for correct operation. If the hardware or
libraries supports NaN correctly, so must LUA. How can we be in a
situation where (7.0>NaN) is true and standard IEEE number handling
is being ignored and standards broken? The problem is not in strtod,
not in ANSI C, or POSIX, not in IEEE, but simply in how LUA
determines ordering from 'lt' and how it handles boolean conditions
I would like to use LUA as the embedded scripting language in a
relational database engine, but I need nil and nan ordering to work
in the correct manner (ie IEEE for NaN). And quite simply it is
currently impossible to convince LUA to work in the correct manner,
because there is only one tag 'lt'.