enhancement proposal for comparisons and containment

[Vincent Delecroix]

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

[Nils Bruin]

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 "==".