#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: analyse recursion
Branch: | error
u/SimonKing/ticket/15303 | Commit:
Dependencies: #14711 | f837cbee8f81c4946a92193c73e86449c53515d9
| Stopgaps:
-------------------------------------+-------------------------------------
Comment (by nbruin):
Replying to [comment:21 SimonKing]:
> Rationale: We suppose that registering coercions happens during
initialisation of the codomain, whereas registering an embedding will
happen ''after'' creation of the codomain. Since the backtracking starts
at the codomain, we should have a clear preference for using those maps
that are closely tied to the codomain---and these are the maps registered
during creation of the codomain.
I don't think that rationale is quite valid for the way it gets used. If
we do
{{{
a+b
}}}
then we'll be investigating whether b can be coerced into the parent of a
and whether a can be coerced into the parent of b. The original question
doesn't actually specify a special role for the codomain (which is still
up for choice!)
It seems to me that you want to argue (and your example backs you up in
this) that while there can be multiple paths in the coercion graph, there
are some paths that should be preferred over others. If we want to model
this properly, we would have to include this information in the graph. One
way would be to give each coercion a "cost" and we'd be looking for the
lowest cost path (which could change with mutations of the graph!).
For your suggestion to fit in such a model, we would need that:
- any path including an embedding is higher cost that a path without.
- if a path has been discovered, new paths between the same parents that
may arise by graph mutations are higher cost
It's not immediately clear to me that those assumptions are valid.
Note: what we're trying to solve on this ticket hasn't actually caused
problems in real life, partly because embeddings are indeed rare. I could
see the temporary outcome of this ticket being "yes, this is a potential
problem, here are a few things we could do to fix it, but the cost of
doing this is considerable. We'll revisit this if we run into a real-life
situation that is actually affected by it".
The current approach is basically one where we ignore the cost of the last
arrow, and otherwise make the cost of an embedding infinity (which gives a
rather odd cost measure, but leads to somewhat desirable behaviour as
we're finding out now)
--
Ticket URL: <http://trac.sagemath.org/ticket/15303#comment:22>
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.
