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

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

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