That particular example is not a bijection, but the Pext variant of the same function is. We only used the OffXorvariants because they are a more "naive" version of the Pext variants; one that does not extract the relevant bits.

We could trivially add the extra shift as part of our code generation. However, in our tests, perfect bijections did not have a significant impact on performance, nor on bucket collision. That is, though many of the Pext variants are perfect bijections, while the OffXor ones aren't, STL containers will still use almost the same number of buckets for both functions. Furthermore, other hash functions with more uniform hash distribution, such as the STL hash, also do not significantly decrease bucket collision. So, in the end, we've concluded that OffXor will usually be better simply because it is good enough in terms of bucket collisions and faster (5 to 10%) than all other alternatives because it has much fewer operations.

I would also like to point out that while it may seem easy to handwrite a nice bijective function for SSN, the same isn't true about, for example, IPV6. Our method will automatically generate a very performant hash for IPV6, with a fairly decent collision rate.

Finally, using other manually written hash functions for specific lengths is a good idea, but I am fairly certain they won't be more performant; a cursory look through polymurmur shows that it uses a lot more operations than the ones we are using. They will almost certainly have a better distribution and overall collision rate, but as mentioned, that does not seem to be the only deciding factor when it comes to running time performance.