#813: forced coercion vs. automatic coercion
------------------------+---------------------------------------------------
   Reporter:  nbruin    |          Owner:  roed      
       Type:  defect    |         Status:  new       
   Priority:  major     |      Milestone:  sage-4.7.1
  Component:  coercion  |       Keywords:            
Work_issues:            |       Upstream:  N/A       
   Reviewer:            |         Author:            
     Merged:            |   Dependencies:            
------------------------+---------------------------------------------------

Comment(by SimonKing):

 The problem with my approach is that it would create a bidirectional
 coercion, namely a coercion from `QQ['x','y']` to `QQ['x']['y']` in
 addition to the coercion from `QQ['x']['y']` to `QQ['x','y']` that already
 exists.

 But I think I have an idea that would solve the problem.

 My original idea was to have a coercion from P to Q if there is a coercion
 from `P.remove_var(Q.variable_name())` to `Q.base_ring()`. That created
 the bidirectional coercion.

 My modified idea is to have the coercion from P to Q ''only'' if
 `P.remove_var(Q.variable_name())` is different from `Q.base_ring()`, but
 coerces into it. Hence, a coercion only takes place if the rings become
 more complicated, thus avoiding circles.

 The tests in sage/rings/polynomial pass. I am now running all doc tests,
 and then I can hopefully submit my patch...

-- 
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/813#comment:11>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sage-trac?hl=en.

Reply via email to