Jeroen Demeyer <j.deme...@ugent.be> added the comment:
> There are _two_ hash functions at play in that collision: the tuple hash > function, and the integer hash function. Regardless of whether the _tuple_ > hash function does [anything involving just `t`], that only directly affects > the result of the _int_ hash function ...which is what you want here. The collision hash((3,3)) == hash((-3,-3)) is due a specific structure in the input to the FNV algorithm. The operation t ^= t << 7 that you suggested (and which I approve, except for the shift amount) is meant precisely to destroy that structure. > If you feel you just have to mess with low-order bits, do it instead on the > _tuple_ hash intermediate results, not on its inputs. It's x you care about > directly, not t. That would not be a good solution, because that destroys the structure of the has algorithm. For Bernstein for example, each loop iteration should do something like x = (x * m) + t for *some* value t depending on the input. If you mess with x, then it really becomes a different hash algorithm. That is far more dangerous than simply applying a permutation on t. > Mucking with t to avoid the nested-tuple catastrophes is worth it, but I > prefer to do that with as little damage to t's desirable properties as > reasonably possible. Which "desirable properties" of t does the operation t ^= (t << 1) damage? ---------- _______________________________________ 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