#15303: Coercion discovery fails to be transitive
-------------------------------------+-------------------------------------
       Reporter:  nbruin             |        Owner:
           Type:  defect             |       Status:  needs_work
       Priority:  major              |    Milestone:  sage-5.13
      Component:  coercion           |   Resolution:
       Keywords:                     |    Merged in:
        Authors:  Simon King         |    Reviewers:
Report Upstream:  N/A                |  Work issues:  Implement
         Branch:                     |  backtracking properly
  u/SimonKing/ticket/15303           |       Commit:
   Dependencies:  #14711             |  74821fe5409c3104b5d6eb7407a8287d54170df9
                                     |     Stopgaps:
-------------------------------------+-------------------------------------

Comment (by SimonKing):

 Replying to [comment:62 nbruin]:
 > So shouldn't the rule be: If `K._coerce_map_from_(L)` returns something
 then one of the following must be true
 >  - There is a registered coercion from L to K
 >  - There is a registered embedding from L to K

 Better: A sequence of registered embeddings and coercions.

 >  - For any structure M that coerces into L, K._coerce_map_from_(M) also
 returns something.

 I think so.

 > > Hence, it is not enough to assign costs to arrows in the digraph.
 >
 > No, "shortcut" paths returned by `_coerce_map_from_` should carry a cost
 as well, obviously. And one would hope their cost roughly corresponds the
 cheapest path that can be discovered otherwise (perhaps with a small
 modifier to make it more attractive to use this particular path).

 Well, the point I wanted to make is: One needs to construct the maps,
 because only the map know about their costs.

 > Aren't the "shortcuts" supposed to be an implementation detail to more
 efficiently implement the theoretical digraph model? In that case we can
 reason about their desired properties purely based on the theoretical
 digraph model.

 Perhaps. But it may also affect lifetime implications.

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