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