#7654: Conversion bug in MPolynomialRing_libsingular
-----------------------------------+----------------------------------------
Reporter: SimonKing | Owner: malb
Type: defect | Status: new
Priority: critical | Milestone: sage-4.7.1
Component: commutative algebra | Keywords: conversion libsingular
Work_issues: | Upstream: N/A
Reviewer: | Author:
Merged: | Dependencies:
-----------------------------------+----------------------------------------
Comment(by SimonKing):
Replying to [comment:7 malb]:
> The attached patch deals with 1) and 2).
Good!
> However, for 3) it currently just raises an error. I'm not sure allowing
more variables in the input ring + matching by index is such a good idea.
Let me know what you think.
I have an argument pro and an argument contra:
I think we agree that the solution for situation 1) and 2) makes sense: It
is "tradition" in Sage to use a position preserving conversion in 2), and
you extended it to 1).
So, why not extending it to 3) as well? Would that be confusing to the
user? Well, if a user is not confused by 2) (which already works in Sage)
then s/he will not be confused by 1) or 3) either.
The argument "pro" is that we have greatest generality, being consistent
with the existing solution 2).
On the other hand, consider the following scenario:
{{{
sage: R.<x,y> = QQ[]
sage: S = QQ['z','y','x']
sage: S(x),S(y)
(x, y)
sage: R(S(x))
x
sage: R(S(y))
y
}}}
That is the current behaviour. But 3) would imply that the conversion from
S to R should be position preserving, and thus R(S(x)) would raise an
error. So, having 3) would mean to change existing behaviour that actually
seems quite natural. That is a strong argument "contra".
Allow me to modify my suggestion as follows:
If the set of variable names of S is a subset of the variable names of R
then we have a name-preserving conversion in ''both'' directions, and the
conversion from S to R is a coercion. Otherwise, we have a position-
preserving conversion in both directions, which is not a coercion.
That would be consistent with the current solution for 2), would coincide
with what your patch does in 1), is consistent with the current behaviour
of R(S(x)) in the example above, and we would ''always'' have a
conversion.
What do you think...
Cheers,
Simon
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7654#comment:8>
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.
