#15303: Coercion discovery fails to be transitive
-------------------------------------+-------------------------------------
Reporter: nbruin | Owner:
Type: defect | Status: needs_work
Priority: major | Milestone: sage-5.13
Component: coercion | Resolution:
Keywords: | Merged in:
Authors: Simon King | Reviewers:
Report Upstream: N/A | Work issues: Crash in permgroup.py
Branch: | Commit:
u/SimonKing/ticket/15303 | 5c0800a07bd83787e59713236e5ccc8dde434760
Dependencies: #14711 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by nbruin):
Replying to [comment:67 SimonKing]:
> Why should `A._coerce_map_from(B)` return anything?
Because if I'm not mistaken, the implementor of A can decide to implement
coercion into A via _coerce_map_from_. Thus we'd have
{{{
class type_of_A(...):
...
def _coerce_map_from_(self,S):
if S is self.C_on_which_A_is_based:
return True
return self._coerce_map_via([self.C_on_which_A_is_based],S)
class type_of_C(...):
...
def _coerce_map_from_(self,S):
if is_instance(S,type_of_B):
return True
<other stuff>
}}}
With this one would get
{{{
sage: A._coerce_map_from_(C)
True
sage: C._coerce_map_from_(B)
True
sage: A._coerce_map_from_(B)
Composite map ...
}}}
As far as I can see (taking, for instance `CC._coerce_map_from_` as an
example) this would be a legitimate way of implementing coercion, and as
you can see, the map found from C to A is explicitly returned, but
consists of maps that are generic conversion maps.
> Aren't you rather talking about `A.discover_coerce_map_from(B)` that
recurses to C and thus calls `C._coerce_map_from_(B)`?
No, I'm talking about implementing part of the coercion graph (with
backtracking on its paths) programmatically as part of the implementation
of a parent via `_coerce_map_from_`. I think this was expressly a part of
the current design and I think there are many examples of this in sage.
Reading the documentation of `discover_coerce_map_from`, it seems that
routine would have the same issue (because it also seems to dislike
`DefaultConvertMap`, and the fragment above shows that it is quite
possible to get a composition of `DefaultConvertMap`s back, which should
be even more disliked)
At this point it seems to me the coercion graphs gets specified in two
ways:
- the `_coerce_map_from_` world, where coercions and backtracking
procedures are provided in a distributed, programmatic fashion. One would
hope that the paths returned by this bit are consistent with what you'd
get from finding paths on an actual graph.
- the `_populate_coercion_lists_` world, which more readily corresponds
to a graph presentation.
The total coercion graph is supposed to be the union of the two, but the
way in which the merger is done seems murky and extremely implementation-
dependent to me at the moment (perhaps because the `_coerce_map_from_`
world is completely implementation dependent by design).
I think we'd need to clarify the relation between the two a little more,
and hopefully formulate some axioms that we can assume the
`_coerce_map_from_` world is adhering to before it's wise to further
complicate the situation by also implementing backtracking along
embeddings.
I think the investigations here are very useful, because I think we are
making explicit a lot of implicit facts and assumptions that have been
floating around in the coercion system and probably got violated in the
organic evolution of the system.
--
Ticket URL: <http://trac.sagemath.org/ticket/15303#comment:70>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.
