[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Proposal: Constant Tables
- From: Lars Doelle <lars.doelle@...>
- Date: Sat, 13 Aug 2011 19:06:21 +0200
> From: Gregory Bonik <email@example.com>
> 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
> 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).
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.