Re: Proposal: Constant Tables

[Lars Doelle <lars.doelle@...>]

> From: Gregory Bonik <gregory@bonik.org>
 
> Beware of floating point non-associativity here. (k, v) pairs can come
> in different order depending on the table's usage history. Combined with
> non-associativity of addition, this can theoretically result in
> different hashes for identical tables. Of course, this problem is not
> likely to occur, but I wouldn't use such solution in a critical part of
> code.
> 
> You should probably use math.random(N) with some integer N instead of
> math.random() and carry out addition by some integer modulo instead of
> just hash_key = hash_key + pair_key(k,v).

Thanks, Gregory.

In princible, one could simply use #basekeys to generate the hashes,
but i thought randoms would be a better start for hashing. If the
associativity does not hold, the problem might indeed occure.

The solution of your follow-up would keep all this on the save side.

As a positive result, btw., i have put some load on the module i posted
and it works amazingly well for a quick shot. My program uses a lot
of structured data as keys, and it was anything but fun coding them
in LUA, which resulted in a lot of spontanous written tables for what
is now done more systematically.

-lars