#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 SimonKing):
I found that the example above has the following structure:
- We have parents `A` and `B`. We search a coercion `A -> B`.
- `B` stores coercions (for backtracking) from parents `C` and `D`. Only
`C` is registered by `B.register_coercion(...)`, whereas the coercion from
`D` was registered in a different way, ''after'' initialisation of `B`.
- There is a coercion `phi` from `A` to `C` and a coercion `psi` from `A`
to `D`. Sage knows that `phi` and `psi` exist. However, calling `psi`
internally relies on a coercion from `A` to `B`.
- The coercion from `A` to `B` '''must''' go via `C`, starting with `phi`.
Otherwise, if one tries to coerce `A` via `D` into `B`, calling `psi` (as
part of a composite coerce map) will result in an infinite recursion.
__Problem with the current commits__
It currently depends on a random choice whether the backtracking algorithm
first goes back from `B` to `C` (and finds a good coerce map from `A`) or
from `B` to `D` (and finds a map from `A` that crashes).
We need to give a hint to the coercion system that it should try `C`
first. In vanilla Sage, this is easy, because the registered coercions are
in a list, and the maps registered first are chosen first. But with my
current patch, all registered coercions and coerce embeddings are stored
in a `MonoDict`. Hence, the order of registration has no implication on
the order of execution.
__Suggested solution__
This brings me back to the idea to keep a '''list''' of registered
coercions, that would automatically keep the domain of registered
coercions alive, and a `MonoDict` of other coercions used for backtracking
(e.g. registered embeddings), whose domains are not necessarily kept
alive.
In discover_coercion, we would then first consider the registered
coercions, and only if their study is complete would the backtracking turn
towards the other embeddings.
__Perhaps useful__
We have `self.register_coercion(mor)`, that adds a coercion to the
''list'' of coercions that the backtracking algorithm is starting with. In
addition, we might have a method `self.additional_coercion(mor)`, that
will put `mor` only in the `MonoDict` of coercions that the backtracking
algorithm is considering only later.
Would this be useful? If "yes", what lifetime implications do we want?
Shall the domain of an "additional coercion" be kept alive?
--
Ticket URL: <http://trac.sagemath.org/ticket/15303#comment:38>
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.
