Help needed again. I removed the (seemingly) useless overrides, but now SetPartition and DecoratedPermutation isn't hashable anymore. Curiously, ParkingFunction is, and I don't see the difference.
On Saturday, 10 December 2022 at 23:45:41 UTC+1 Martin R wrote: > https://trac.sagemath.org/ticket/34824 now removes the parent from the > hash, and all the overrides I could find. > On Friday, 9 December 2022 at 23:03:38 UTC+1 Nils Bruin wrote: > >> On Friday, 9 December 2022 at 02:49:12 UTC-8 axio...@yahoo.de wrote: >> >>> Would it make sense to have a subclass, or perhaps an option to >>> ClonableArray.__init__, that determines whether or not to include the >>> parent into the hash? The current behaviour seems rather error prone to me. >>> >> >> I think we've identified that there are definitely cases where having >> parent *not* included in the hash for certain versions of ClonableArray is >> beneficial. I'm not sure we have a convincing case where having the parent >> in the hash IS beneficial. A scenario where this would be the case would be >> if somewhere we end up with sets/dictionaries with loads of (non-equal) >> instances of ClonableArray such that tuple(...) hashes to the same value. I >> think it's unlikely that distinguishing on parent in the hash is ever a >> performance-essential feature. So it may be reasonable to change the hash >> function for all of them. >> >> If there are cases for both then the appropriate way is via overriding >> the hash on subclassing, not introducing extra flags on the init method: >> hash gets looked up via special method slots, so you should just make sure >> that the class has the right function registered. There's a mechanism for >> doing so: overriding methods in subclasses. >> >> On the other hand, I am not sure whether GF(3)(4) == ZZ(4) is desirable. >>> >> >> It's basically a corollary of being able to write GF(3)(1) + 1 . You'd >> end up with a system that is very painful to use interactively if you >> wouldn't allow for that (but, yes: coercion through quotient maps is >> definitely more problematic than through inclusions). >> > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/3b8e387b-da27-4810-865a-db97e5218e5bn%40googlegroups.com.
