[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
**Subject**: **RE: Lua hash algorithm**
**From**: "Curt Carpenter" <curtc@...>
**Date**: Wed, 19 Jun 2002 13:11:04 -0700

> Code that generates indices using floating point computation is
subject to interesting surprises, for example:
>
> [using Lua 4 on Win32]
> > k=99999
> > i=1/k
> > j=1/i
> > t={}
> > t[k]=1
> > print(t[j])
> nil
>
> Here's why:
> > print(j-k)
> 1.164153218269348e-010
>
> Of course, it's easy to generate other examples. But perhaps folding
down to ints would be better.
FWIW, I get 1 and 0 respectively.
Anyway, round off errors are well understood, so clearly a "best
practice" would be to not rely on such behavior for values of indices. I
don't think forcing all numeric indices to ints would really solve
anything. In your example (or some other contrived example) it's easy to
see how two mathematically identical expressions could evaluate to like
1.00001 and .99999, and if you're just going to use the floor you still
have different values for the index. You could make an argument for
arithmetic rounding, but that just seems weird.
The real solution (not that I'm requesting it, but...) to the rounding
problem would be to have a native integer data type (discussed many
times). And you could choose to index with an integer instead of
floating point (or string or table).
Curt