#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.

Reply via email to