ad-hoc __hash__ methods

38 views
Skip to first unread message

Lorenz Panny

unread,
Oct 20, 2021, 11:56:21 PMOct 20
to sage-...@googlegroups.com

I've seen handrolled __hash__ methods in quite a few places: They
usually take individual hashes of the data defining the object and
combine them in some arbitrary-looking way.

Two examples I came across recently:
https://github.com/sagemath/sage/blob/9.4/src/sage/schemes/elliptic_curves/ell_curve_isogeny.py#L1216
https://github.com/sagemath/sage/blob/9.4/src/sage/algebras/quatalg/quaternion_algebra_element.pyx#L219

Q: Is there a good reason things done like this, rather than just
calling hash() on a tuple containing the data of the object?

Nils Bruin

unread,
Oct 21, 2021, 1:45:38 AMOct 21
to sage-devel
I guess you're worried that h ^= h1; h ^=h2 gives the same result as h ^=h2; h ^=h1 ?
I think it makes sense to combine hashes without making an intermediate tuple. That would be unnecessary overhead. On the other hand, python's tuple hash indeed is quite careful to mix the consecutive object hashes quite carefully:

Vincent Delecroix

unread,
Oct 21, 2021, 5:10:55 PMOct 21
to sage-...@googlegroups.com
There is a lot of incoherence and inconsistencies in sage
hash functions. Two reasons that might explain the design in
some particular situation

* high hash collisions with tuple of integers in Python
(because hash(-1) is -2)

>>> hash((-1,-2)) == hash((-1,-1))
True

* speed. With your version the code would create a tuple (admittedly
this is rather fast).
Reply all
Reply to author
Forward
0 new messages