Re^8: RFC: Is there a solution to the flaw in my hash mechanism? ($o != $i)

I'm not convinced that either of those is required. But I'll refrain from trying to make a case stronger than that at least at this point.

How would you distinguish between an empty slot and one that is in use other than by reserving one value from the input range (0 .. 2**64-1) as a sentinel or tell tale value?

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^8: RFC: Is there a solution to the flaw in my hash mechanism? ($o != $i)

Replies are listed 'Best First'.
Re^9: RFC: Is there a solution to the flaw in my hash mechanism? (sentinel) by tye (Sage) on Jun 03, 2015 at 13:49 UTC
Sorry, I mistook the context of that statement due to lazy reading. Another approach would be a bitmap. You could even avoid a bitmap by, for example, sharding odd hash values into one hash table and even hash values into a second hash table. Then the 0 bit could indicate "empty" though the meaning of the value of that bit would be reversed between the two tables. - tye	[reply]