The author doesn't mention deletion (which is actually the most problematic part of open-addressing hash maps). If you use gravestones (which is the solution most people take) you end up with wasted space. You can optimise it slightly by retaining the stored key in the gravestone so if the key is set again, you can reuse that spot. However, and more optimisation starts causing orphaning problems. This is why I much prefer buckets because lots of removals don't incur a sudden performance penalty.<p>Also, I can see that if your first delta hits another probe chain's beginning, then you'll end up with the same chain. This is slightly solved by quadratic probing, where your first and second multipliers have differing effects on the output so two chains that meet once aren't forever locked together. Maybe if you incorporated some of the quadratic effect into Leapfrog this issue might be alleviated.
It would have been nice to have some context with regards to the algorithm being explored. Although some ideas seem pretty clever, I've too often seen code implementing this in a haphazard way (buggy, no comments). This leaves the next programmer scratching their head and wondering ... why?
Unless you have very specific performance and memory constraints, I do not see the need for such structures in most every programmers daily business.
Also an interesting variation on hash tables is the Cuckoo Hash (<a href="https://en.wikipedia.org/wiki/Cuckoo_hashing" rel="nofollow">https://en.wikipedia.org/wiki/Cuckoo_hashing</a>). However, I don't think it makes a lot of effort in keeping marching keys near to each other, so I suspect Leapfrog probing might cause less cache misses.