#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 | 74821fe5409c3104b5d6eb7407a8287d54170df9
| Stopgaps:
-------------------------------------+-------------------------------------
Comment (by nbruin):
Replying to [comment:45 SimonKing]:
> I wonder: Do we really insist on making the example from the ticket
description work?
>
> There are typical parents (e.g., CC) that have numerous registered
coerce embeddings from other parents (e.g., from number fields). If we try
to find a coercion from P into CC, it would normally not help to first
search for a coercion from P into a number field instead.
Ah right, you're saying there are certain "almost universal terminal"
objects that tend to have a very large in-degree. Doing backtracking from
them would be a rather expensive operation (independent of whether it's
breadth-first (cheapest-first is a better name) or depth-first). So we
mandate that any paths that would involve such a map should be explicitly
offered, so that backtracking is not necessary for discovering paths that
use it. That could make sense. In order for such a model to be usable,
you'd have to write clear documentation/helper routines to ensure that the
right maps are put in. What if discovery is needed in the process of
finding coercions between polynomial rings/function fields/algebraic
groups over certain bases etc? Can we write down rules that make for a
transparent and usable model?
> So, perhaps we could say that registered embeddings should be ignored in
backtracking (as they are now). If one wants something like the example
from the ticket description, one should ''not'' use
`.register_embedding()`, but do something like this:
> {{{
> C.coerce_map_from(B) # returns None, since we have no A yet
> A.register_coercion(BtoA)
> AtoC.register_as_coercion() # should increase the cache version number
according to the Lemma
> C.coerce_map_from(B) # now returns a coercion via A, because the cached
absence of a coercion
> # will be ignored after the increment of the
version number
> }}}
Hm, where does `AtoC.register_as_coercion()` fit in with the "only
initialize coercions upon `__init__` of the parent"?
> Do you agree on this change of aim?
Well, I think what you're saying is that under certain conditions we
require that the graph is fed more than just the backbone. Instead of
relying on the coercion system to discover the full transitive closure, we
mandate that the graph as offered should already be transitively closed in
some aspects. If you can make those aspects clear and workable, I guess
that could be a solution too.
--
Ticket URL: <http://trac.sagemath.org/ticket/15303#comment:46>
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.
