#14711: Weak references in the coercion graph
-------------------------------------+-------------------------------------
Reporter: jpflori | Owner: davidloeffler
Type: defect | Status: needs_work
Priority: critical | Milestone: sage-5.13
Component: number fields | Resolution:
Keywords: memleak, number | Merged in:
field, QuadraticField | Reviewers:
Authors: Simon King | Work issues: String repr. of
Report Upstream: N/A | weakened maps; copying/pickling of
Branch: | maps
u/SimonKing/ticket/14711 | Commit:
Dependencies: | 5168cfd15d4cdbaa3ffdbd4be0f7d783f77257c7
| Stopgaps:
-------------------------------------+-------------------------------------
Comment (by SimonKing):
Replying to [comment:120 nbruin]:
> And the "weakened" copies of maps (with in the near future an easily
distinguished string rep) would be ''equal'' to their counter parts?
Of course. Equality does (and should) not depend on weak references, I
think
> I don't think in coercion we ever depend on equality testing on maps do
we?
We don't. Otherwise, people would have had comparison implemented already.
> I think it's better done on a separate ticket.
Agreed.
Concerning "near future": I am already testing a new commit that provides
- special string representation for weakened maps
- copying for ''all'' maps and morphisms (at least those that I was able
to find in the sources). It was very dull work: Look up the cdef slots,
implement `_extra_slots` and `_update_slots`, add a test...
- Use the copy functionality on most tests that expose coerce maps. Hence,
I replace
{{{
sage: R.coerce_map_from(P)
...
}}}
by
{{{
sage: copy(R.coerce_map_from(P))
}}}
and also add a link to this ticket. Not everywhere, but in most places.
> Another suggestion about how to get the the strong references in for
register_coercion. If the maps put in by register_coercion are used
afterwards many times to derive other cached coercion maps from, it would
perhaps be preferable to have them in a form that is readily usable for
that, i.e., as "weakened" maps (it means the map can go straight into map
compositions etc.). Otherwise we may well end up making copies repeatedly
in the coercion framework.
Why do you think they would/should be copied ''inside'' of the coercion
model? I thought we already had agreed that copying is needed when
exposing a coerce map to the user (this is why I suggested that the string
repr contains a warning!). But certainly not internally. This would be by
far too slow.
Suppose you have two non-weakened maps phi and psi, and then do `chi =
phi*psi` (a composite map). When you then weaken `chi`, neither `phi` nor
`psi` would be changed. So, why copying?
> We could get the strong connections in by, for instance, referencing the
domains explicitly, say on an attribute
`_domains_with_registered_coercions_to_here`.
This is already done in my current branch, and it is called
`_registered_domains` (simply a list).
> The coercion map itself could simply live in the normal cache, as a
weakened map.
No, because we need some container that ''only'' stores those maps that
are considered in the backtracking algorithm. So, the current separate
list `_coerce_from_list` must be preserved.
> The same applies to `_register_embedding`, although perhaps the coercion
discovery treats the store differently, and storing a strong reference to
even a weakened map implies a strong reference to the codomain.
All weakened maps still have a ''strong'' reference to the codomain. Only
the reference to the domain will be weak. And `register_embedding` is
still simply assigning the embedding to an attribute `_embedding` of the
domain.
> Other question, does `_parent=None` imply a weakened map? (I guess
isinstance(_domain,weakref.ref) definintely does) or are there other
reasons for the parent to be unset?
I guess one could test `self._parent is None`, rather than typetest stuff.
This should actually be faster.
Concerning "reasons": The parent is unset, because otherwise we have a
chain of from references from the map to the domain, namely via the parent
(i.e., the homset). Hence, having a weak reference from the map to the
domain would be futile if there is a reference from the map to its parent.
Note that alternatively one could have a weak reference from the
''homset'' to the domain. But I think we have agreed above that we don't
want this as a default.
--
Ticket URL: <http://trac.sagemath.org/ticket/14711#comment:121>
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.