#14711: Weak references in the coercion graph
-------------------------------------+-------------------------------------
Reporter: jpflori | Owner: davidloeffler
Type: defect | Status: needs_review
Priority: critical | Milestone: sage-6.1
Component: number fields | Resolution:
Keywords: memleak, number | Merged in:
field, QuadraticField | Reviewers:
Authors: Simon King | Work issues:
Report Upstream: N/A | Commit:
Branch: | 37bf59eac24eda1ece89aff7dde4a1db5d0cbb5c
u/SimonKing/ticket/14711 | Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by nbruin):
Replying to [comment:166 SimonKing]:
First of all, indeed someone SHOULD go ahead and review the ticket. I'm
just not
comfortable with the sage coercion system (even after spending some time
trying
to become familiar with it), so it's not me.
> That's to say (@Nils): A coercion model (partially) relying on
backtracking ''MUST'' have lifetime implications for the parents involved,
simply to keep the backtracking algorithm functional. But ideally, all
caching-for-efficiency and short-cutting done on top of backtracking
algorithm should have no ''additional'' lifetime implications.
Apart from intermediate parents involved in composed maps: I don't think
so. If
you're working with finitely generated structures then any homomorphism
can be
given by images of generators, which in the end could be encoded as lists
of
(lists of) integers. So the defining information of a homomorphism doesn't
have
to hold explicit references to the (co)domain, and furthermore a
composition of
homomorphisms doesn't have to refer to the homomorphisms it is composed
of: one
just needs to store the images in the final codomain of the generators of
the
initial domain. The homomorphism can then just store weak references to
domain
and codomain to check that when it's used, the domain and codomain are
still
available.
> The last point is another benefit of this ticket: It is supposed to
implement
> copying (and thus, pickling!!) of all maps in Sage!
That's great.
> > Ideally, the patch might fix some of the horrible name choices in the
coercion framework.
> That's not the purpose of this ticket.
OK, I thought we had some steps in that direction somewhere; just not here
then I guess.
> [`_coerce_map_from_`] is only ''one'' tool. And if I am not mistaken
about Sage's history,
> `_coerce_map_from_` was predated by a pure backtracking approach, that
has
> turned out to be not flexible enough.
Predated by a model that I think basically needed to be ripped out. If I'm
not mistaken about a
conversation in 2007 with Robert, when he was working on the framework we
have now, the idea was that
MOST parents would solve their coercions via this programmatic tool,
because they would probably know
best to do it. The lists of maps used for automatic backtracking were
supposed to be relatively short.
> > It is responsible for ensuring generating results that are consistent
with the fact that path-connectedness is closed under composition.
>
> ... which is dealt with on a ''different'' ticket. Please don't prevent
this
> ticket from review just because it only addresses ''one'' flaw of the
current
> coercion model.
"It" being the parent that implements `_coerce_map_from_`, not this
ticket. This remark was not meant to
state anything about the reviewability of this ticket.
--
Ticket URL: <http://trac.sagemath.org/ticket/14711#comment:167>
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.
