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
