On Sunday, August 16, 2020 at 4:22:22 AM UTC-7, Dima Pasechnik wrote:
>
>
> I guess this has to do with Python hashing; objects are not checked
> for `==` equality when you do {},
> but for equality w.r.t. to certain internal representation:
> sage: g = libgap.SymmetricGroup(3)
> sage: x = g.Subgroup(libgap.eval('[(1, 2), (2, 3)]'))
> sage: y = g.Subgroup(libgap.eval('[(1, 3), (2, 3)]'))
> sage: z = g.Subgroup(libgap.eval('[(1, 3), (2, 3)]'))
> sage: len(libgap.Set([x,y,z])) # so this is sane on GAP/libgap level
> sage: len({x,y,z}) # but!
> 2
> sage: x==y, y==z, x==z # while this makes sense
> (True, True, True)
>
>
No, it means that libgap breaks the __hash__/__eq__ contract in python.
Python sets do not compare wrt. internal representation. They just assume
that objects that test equal have equal hashes. When you can't compute a
hash that respects equality, then you shouldn't make your object hashable.
Given the variety of objects that libgap implements, I think libgap should
not support hashing. It may be possible to skirt the rules a bit and make
some nicer objects hashable, but if we're just going to allow hashing of
everything, I think errors like this are unavoidable. Alternatively, we can
implement a constant hash function for them. That would revert everything
to equality testing, and would completely break performance in python.
--
You received this message because you are subscribed to the Google Groups
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-support/3e1cf0fd-af6e-4b92-969a-628c55cb1d7ao%40googlegroups.com.
