Re: LUA4.0 : Bug with maths

["paulmatthews" <paulmatthews@...>]

--- 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!).
> --lhf
>

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. 

  function lt(a,b)
    r = cmp(a,b);
    if r == nil  then
      return nil;
    end
    return r<0;
  end;

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 
in general.

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

--
Paul Matthews