While I don't have a particular objection against the notion of "intersection" of parents, I don't think it belongs in the coercion system, because I think its only uses run counter to what I think the coercion system is/should be designed for.
The most complicated part of the coercion system deals with figuring out (hopefully consistent) domain/codomain choices for binary operations: given two parents A and B and a binary operation f, find an appropriate parent C so that the map f: A x B -> C works as expected. In many cases, this means finding a common overparent together with coercion maps A->C, B->C so that we can just use the preexisting f: C x C -> C. but in the case of actions (or scalar multiplications), it's a little different: in those cases there is usually a map, say f: R x B -> B and the search for meaning is limited to finding a suitable coercion A->R (automatic base extension of vector spaces upon scalar multiplication is not something we're currently doing; probably because it will often hide/defer errors rather than be a convenience) The important part here is that the resulting map f: A x B -> C is actually a map; not a partial one. I have trouble seeing how "intersecting" parents would ever be useful in that setting. It seems to me that intersection(A,B) should be relative to a common overparent A->C, B->C (perhaps one that can be discovered, but note that the C the coercion system computes is also a function of the operation) and then is a "maximal" D that coerces into A,B such that D->A->C and D->B->C agree. For that to be useful for anything, there should then also be a partial conversion maps A->D, B->D that are inverses to the coercions. As far as #4621 goes: Just as with "==", I don't think a "False" from "in" should be taken as: "definitely does not lie in" but more as "system cannot figure out if it does". Transitivity already breaks for us for "==", for fairly fundamental reasons, so I think it's acceptable with the same being true for "in". Our equality test should really be tri-valued and be guided by the coercion framework: if there's a common parent for testing "==" then we can do it there; otherwise we answer "don't know". That obviously doesn't map onto the python requirements of "==". On Saturday, March 27, 2021 at 10:58:19 AM UTC-7 vdelecroix wrote: > Dear all, > > This is a proposal to implement a new operation somewhere in our > coercion model: intersection of parents. The motivation is to > enhance > > 1. comparison: x == y would work as expected when x and y belongs to > the intersection of their parents (see [#4621] for a use case) > > 2. conversion: P(x) would work when the intersection of P and the > parent of x contains x. > > By default, the intersection of two parents A and B would be None. > Otherwise it would return a parent that has an injective coercion > in both A and B with the requirement that intersection(A, B) is the > same thing as intersection(B, A). > > Does it make sense? > > [#4621] https://trac.sagemath.org/ticket/4621 > > Best > Vincent > -- 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/22f586ef-e007-484a-8025-7341d32b63f8n%40googlegroups.com.
