Re: Lua 5.1 (beta) now available

[Rici Lake <lua@...>]

On 21-Nov-05, at 10:45 AM, Mike Pall wrote:

> I don't care so much whether NaN can be inserted or not or
> whether it can be retrieved or not. But breaking table traversals
> is not a good idea IMHO.

I agree with this.

NaN's seem to cause problems for almost all languages, I doubt whether 
there is a really good solution which would be acceptable to everyone.

My reading of IEEE-754r is that it does not prohibit the implementation 
of an "is identical to" operator which would return true when comparing 
a NaN to itself. Unfortunately, such an operator would also return 
false when comparing 0 to -0, amongst other cases. That would be 
confusing, so a reasonable compromise would probably be to do the 
equality test in hash lookups something like this:

  if ((a == b) || representation_equal(a, b)) ...

where representation_equal(a, b) is implemented similarly to the 
hashing algorithm (i.e. word by word comparison).

As a side-node, the normalization step (a = a + 1.0) in the hashing 
algorithm is certainly correct for ieee-754 binary floating point 
(although I believe it may fail to normalize decimal floating point 
numbers) but it is amazingly slow on Pentiums if given a NaN or an 
infinite.