#14711: Weak references in the coercion graph
-------------------------------------+-------------------------------------
Reporter: jpflori | Owner: davidloeffler
Type: defect | Status: needs_review
Priority: critical | Milestone: sage-5.13
Component: number fields | Resolution:
Keywords: memleak, number | Merged in:
field, QuadraticField | Reviewers:
Authors: Simon King | Work issues:
Report Upstream: N/A | Commit:
Branch: | 364b9856b28d7060e3ea9825144de66c8f11ca2a
u/SimonKing/ticket/14711 | Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by SimonKing):
Replying to [comment:131 nbruin]:
> > The punchline is: '''If `chi` is discovered by backtracking then `psi`
is
> > stored in `C._coerce_from_list`.''' Without `psi` being on this list,
> > backtracking won't find `chi`.
Modulo the oversight I have corrected in my previous posts:
If a composed map `chi` is discovered by backtracking, then either the
second map is registered as a coercion (hence, C keeps B alive) or the
first map is the coerce embedding of A (hence, A keeps B alive). But, as I
have shown, storing the composed map as coercion from A to C (in
`C._coerce_from_hash[A]`) does not cause a leak, at least not with the
attached branch.
> Right, I was already expecting something along these lines when you
explained the function of `coerce_from_list`: The backbone of the coercion
framework presently requires lifetime specifications to be explicit and it
seems this is not just a by-product of the implementation, it seems to be
part of the spec. That's fine by itself. Whether having such implications
is sufficient for sage in the future remains to be seen, but changing that
is a redesign problem that would need to be carefully considered
Agreed. Currently, the coercion system operates on a virtual digraph, and
I could actually imagine that this digraph could become an actual object
with a fast graph backend. This might give more flexibility for our
coercion system. But this would require a major rewrite.
> (just as it might be desirable to allow multiple embeddings to be
registered)
Why? What should be done with these embeddings?
--
Ticket URL: <http://trac.sagemath.org/ticket/14711#comment:132>
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.
