Re: RFC: Is there a solution to the flaw in my hash mechanism? (And are there any others?)

I'm not sure I've captured all of the comments here, but here's my suggestion: Use the value at the hash collision to get the offset for the next hash key. If the hash value is 0 mod $PRIME, use half the prime as an offset, to avoid clustering. In Perl, if you will:

my %hash; # hash of stored values
my $PRIME = some_large_prime(); # random or fixed, your choice
my $PRIME_HALF = int($PRIME/2); # or some other known value or functio
+n
...
my $i = $initial_index; # wherever you get this from
my $failed_tries = $PRIME;
while (defined($hash{$i}) and $failed_tries--) {
    my $offset = $hash{$i} % $PRIME;
    $offset = $PRIME_HALF if ($offset == 0);
    $i = ($i + ($hash{$i}) % $PRIME;
}

if ($failed_tries) {
    $hash{$i} = $value;
} else { 
    warn "Hash full\n";
}
[download]

Update: I'm assuming that the hash values, once written, are read only, and never change.

-QM
--
Quantum Mechanics: The dreams stuff is made of

Comment on Re: RFC: Is there a solution to the flaw in my hash mechanism? (And are there any others?) Download Code

Replies are listed 'Best First'.
Re^2: RFC: Is there a solution to the flaw in my hash mechanism? (And are there any others?) by BrowserUk (Patriarch) on Jun 03, 2015 at 01:15 UTC
Use the value at the hash collision to get the offset for the next hash key. Problem. The value giving the trouble is 0; so the value at the hash collision can be 0; and 0 + 0 == 0 :) Of course, it won't always be zero. Any multiple of the Prime size will mod to a hash of 0; but is still means that if a true 0 value arises, the thing disappears up it you know where. Having spent the last 3 days running some long-running, large scale simulations; I'm satisfied that the benefits of the declustering affect of the i⁺¹ = ( i + prime ) % prime scheme are real, and outweigh the need to have an `if( !i ) { //take a different path` conditional test in the inner loop. I'm still trying a couple of things for that other path; but adding prime/2 seems as good as any other thing I've thought of. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". I'm with torvalds on this In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked	[reply] [d/l]

Replies are listed 'Best First'.

Re^2: RFC: Is there a solution to the flaw in my hash mechanism? (And are there any others?)
by BrowserUk (Patriarch) on Jun 03, 2015 at 01:15 UTC

Use the value at the hash collision to get the offset for the next hash key.

Problem. The value giving the trouble is 0; so the value at the hash collision can be 0; and 0 + 0 == 0 :)

Of course, it won't always be zero. Any multiple of the Prime size will mod to a hash of 0; but is still means that if a true 0 value arises, the thing disappears up it you know where.

Having spent the last 3 days running some long-running, large scale simulations; I'm satisfied that the benefits of the declustering affect of the i⁺¹ = ( i + prime ) % prime scheme are real, and outweigh the need to have an if( !i ) { //take a different path conditional test in the inner loop.

I'm still trying a couple of things for that other path; but adding prime/2 seems as good as any other thing I've thought of.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I'm with torvalds on this

In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked

[reply]
[d/l]