New answers tagged hash-tables
0
In double hashing, we have (for a specific k) the series h(k) + nh'(k) mod m (sorry im new and not sure about the syntax of math objects in stack exchange)
Since we have that gcd(h'(k), m) = 1 (they are relatively prime), then from Bézout's identity there exists two integers a,b such that ah'(k) + bm = 1. since h'(k) is not 0, we can conclude that b is not ...
0
The best way to avoid collisions is to keep the number of slots large enough. You say "retrieval is too slow" - how slow? You need at the minimum one calculation of a hash key, one comparison, plus one comparison per collision. If you have more than one collision on average, either your hash table doesn't have enough slots, or something is very wrong with ...
0
hash = (hash + getChar(strlen, i)) * 123456791
0
It makes the hash table unusable if I can’t have x and yz and abc as keys.
2
Sure. Any Turing machine can be represented as a bit string (print out the description of the Turing machine). Any bit string can be encoded as a natural number (prepend a 1 bit, and view it as a binary representation of a number).
1
it may be better to store them in separate hash table. or, if you need them in the same table:
tmp = position
if (makeItUnique)
tmp := [memory address of position object]
hash = zobristHash(tmp);
It's better than your current code since it will avoid collisions of objects with the same position AND similar memory address (the definition of similarity ...
0
I don't see any reason to expect this to increase the chance of collisions. If the data in the object and the address of the object are independent, then XOR does not cause any harm.
It might be even simpler and faster to use a hash of the address, without hashing the object contents, when you want it to be unique.
Top 50 recent answers are included
