This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tim.peters
Recipients eric.smith, jdemeyer, mark.dickinson, rhettinger, sir-sigurd, tim.peters
Date 2018-10-01.22:33:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
>    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 :-(
Date User Action Args
2018-10-01 22:33:09tim.peterssetrecipients: + tim.peters, rhettinger, mark.dickinson, eric.smith, jdemeyer, sir-sigurd
2018-10-01 22:33:09tim.peterssetmessageid: <>
2018-10-01 22:33:09tim.peterslinkissue34751 messages
2018-10-01 22:33:08tim.peterscreate