Extensible hashing: why does anyone use the most important bits?

When encoding extensible hashing, you can choose to use the most significant bits or the least significant bits of the hash value to determine which bucket the hash belongs to. Using the least significant bits has several advantages:

  • When you duplicate a directory, you can simply copy all the pointers, instead of creating a new directory that interleaves them.
  • You can simplify the discussion of the algorithm without even talking about bits at all, and simply using modular arithmetic, as is the case with hashing in general. Using the 3 least significant bits to select a bucket is the same as h (x) = x mod 2 ^ 3.
  • You do not need to specify the width of the binary numbers in advance; if you use the most important bits, you need to have a specific bit length in memory.

What I can’t wrap is why the link after link after link shows extensible hashing done using most of the significant bits. As far as I can tell, the only advantage that gives the most significant bits is the chart on paper (or on the screen), which has no intersecting lines. Is there a good reason why there are so many sources, so the most significant bits, not less?

+5
source share
1 answer

Finally, I returned to the original source article from Fagin, et. and others. They refer to this:

β€œNote that if we used pseudo-suffixes rather than prefixes, then the algorithm for doubling the directory would be especially easy: it essentially consists in making a second copy of the incomplete part of the directory immediately after the first instance. However, we decided to use prefixes for the sake of intuitive simplicity (thus, using prefixes, keys can be easily accessed in the pseudokey order, rather than in an inverted pseudo-key order). "

I don’t understand why they considered this approach more intuitive, since you could do without the idea of ​​a whole bit and use modular arithmetic instead, but it seemed to be at least their rationale.

+2
source

Source: https://habr.com/ru/post/1206593/


All Articles