I accidentally opened a new ticket https://trac.sagemath.org/ticket/34824, which is essentially ready for review. There is another problem, which I do not understand, which may be dealt with in the same ticket, if it is easy:
sage: P = ParkingFunctions(4) sage: B = P([1, 2, 3, 4, 5, 6]) sage: B.parent() Parking functions of size 4 sage: B in P False On Sunday, 4 December 2022 at 21:07:51 UTC+1 Nils Bruin wrote: > It looks like just overriding `_hash_` should do the trick. It's a "cpdef" > method so the code should be there to check if it's overridden on a > descendant class instance. There will be a performance degradation, > although it will be mild because the hash is cached. If that's a problem, > you can cythonize ParkingFunction and override the whole equality and > "__hash__" infrastructure on the class. If that's too much work it's an > indication that perhaps it's not such a big problem :-) > > The workaround is to just not use the specialized "ParkingFunctions of > fixed length" parents, so that all the parking functions you use have the > same (generic) parent. Or only use specific parents, depending on what is > more suitable for your code. More generally "sets with elements from mixed > parents" are not really supported or at least buggy; because of the > fundamental problem with transitivity of equality (and the interactions > with hash). > > While for parking functions this may be relatively solvable, you should > consider the problem you're running into a code smell. Defensive coding > practices in sagemath would avoid these constructions in the first place. > It's not really ideal to have undocumented or unenforced recommended > practices, but in this case it's a consequence of the requirement in > sagemath to stretch equality notation to something that globally is no > longer transitive, together with sets that don't know about parents or > coercion. A mitigating workaround would be a set that is aware of the > parent of its elements. Then testing membership can coerce the candidate > into the appropriate parent (if that fails, it can't possibly be in the > set) and then hashes only need to be consistent with equality within the > parent. If that's not the case, you tend to really have a bug, rather than > just an inconvenient instance of inconsistencies that are bound to exist. > -- 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/63947b3a-c18b-4a90-9236-5caac2b6a3b0n%40googlegroups.com.
