#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 nbruin):

 I'm not so sure that the coercion system was designed with embeddings as
 an ''alternative'' to registered embeddings: If you register a map only as
 an embedding (and not also as a coercion on the codomain) you can end up
 with the coercion system yielding non-transitive results:
 {{{
 class pA(Parent): pass
 class pB(Parent): pass
 class pC(Parent): pass

 A=pA()
 B=pB()
 C=pC()

 BtoA=Hom(B,A)(lambda x: A(x))
 AtoC=Hom(A,C)(lambda x: C(x))
 A.register_coercion(BtoA)
 A.register_embedding(AtoC)

 C.coerce_map_from(A) #finds the right map
 A.coerce_map_from(B) #finds the right map
 C.coerce_map_from(B) #returns none!
 }}}
 (other combinations of using `register_coercion` and `register_embedding`
 do lead to the appropriate discovery)

 so, if we want to view the coercion framework as a digraph and valid
 coercions as paths in this digraph, then an arbitrary combination of
 `register_embedding` and `register_coercion` may lead to invalid
 manipulations of the graph (i.e., leading to a state where the system
 fails to provide consistent (transitive) results).

 This wasn't such a problem before, but since we are now tying lifetime
 implications to how a coercion is registered, I think it now becomes
 apparent.

--
Ticket URL: <http://trac.sagemath.org/ticket/14711#comment:134>
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