Tim Peters <t...@python.org> added the comment:
> Py_uhash_t t = (Py_uhash_t)y; > x ^= t ^ (t << 1); > x *= (Py_uhash_t)0x6eed0e9da4d94a4fULL; > x ^= (x >> 32) >> (x >> 60); > x *= (Py_uhash_t)0x6eed0e9da4d94a4fULL; Comment out either one of the multiplies, and it still passes all the tests. Commenting out the first one is "more valuable", because on all but the last loop iteration the latency of the last-line multiply will overlap with the next call to hash a tuple component. It even reduces the number of collisions in the new tuple test (down to 7 - and still no collisions at all in other tests). I'm not clear on why there are two multiplies. With both, or either one alone, low and high bits still get their chances to affect the other end. Presumably it boils down to some detail in "the proofs" - but, as for FNV, while various things are _claimed_, I can't find a writeup of "the proofs" anywhere :-( ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue34751> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
