#18282: Improve the default evaluation method for univariate polynomials
-------------------------------------+-------------------------------------
Reporter: mmezzarobba | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.7
Component: commutative | Resolution:
algebra | Merged in:
Keywords: | Reviewers:
Authors: Marc Mezzarobba | Work issues:
Report Upstream: N/A | Commit:
Branch: | 89671731fdf80e827f11b120a6655659c28c0225
u/mmezzarobba/wip/pol_of_symb | Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by mmezzarobba):
Replying to [comment:8 nbruin]:
> {{{
> sage: pol(y, 0)
> 1000*x^2*y^2 + 100*y + 10*x + 1
> }}}
> If I understand correctly, you now make this evaluate to `100*y+1`?
Yes:
{{{
sage: pol(y, 0) # with patch
100*y + 1
}}}
Note that the previous implementation wouldn't work in the case of `pol(y,
0)`, but would happily compute
{{{
sage: sage: pol(y+1, 0) # without patch
100*y + 101
}}}
> In which ring? You've evaluated `x`, so the answer should lie in
QQ['y'], which is not a ring that exists at this moment.
Not exactly:
{{{
sage: pol(y, 0).parent() # with patch
Univariate Polynomial Ring in y over Univariate Polynomial Ring in x over
Rational Field
}}}
The logic here is that yes, I have evaluated x, so the evaluated
coefficients lie in ℚ, ''but'' then I'm evaluating the resulting element
of ℚ[Y] on y ∈ ℚ[x][y], not y ∈ ℚ[y]. So the answer should lie in ℚ[x][y].
In contrast,
{{{
sage: pol(0, x).parent() # with patch
Univariate Polynomial Ring in x over Rational Field
}}}
since `x.parent()` is `QQ[x]`, not `QQ[x][y]`.
> What about `pol(y,I)`? should that return an answer in
`QuadraticField(-1,name="I")['y']`?
{{{
sage: pol(y, I).parent() # with patch - TBI, see #18036
Symbolic Ring
sage: pol(y, I.pyobject()).parent() # with patch
Univariate Polynomial Ring in y over Univariate Polynomial Ring in x over
Number Field in I with defining polynomial x^2 + 1
}}}
> Furthermore, the rings in which the answer is supposed to lie likely
don't exist yet. Letting sage choose which rings should be constructed
likely leads to difficult to predict behaviour (you'd basically be relying
on the common parents the coercion framework cooks up,
Well, yes, but that's already the case when you just do `a + b`! Would you
really want the evaluation of elements of ℤ[x][y] on y = y0 ∈ ℚ to raise
an error?
> I think that `pol(y,0)` should be an error because there's an unhandled
coefficient `0` present. It's not clear at all that the *second* argument
should be used for the variable that gets mentioned *first* in
`QQ['x']['y']`. One might think that `pol(y0,x0)==pol(y0)(x0)`, but that's
not the case either. Error really is safer.
Perhaps, yes, but I didn't invent this feature. It has been present for
years, and people use it! There are even examples in the sage library that
rely on `pol(y,x)` working when pol ∈ R[y] where R is ''not'' a polynomial
ring (but another ring with callable elements). So really this ticket is
only about making the implementation understandable, and fixing lots of
corner cases such as those mentioned above.
--
Ticket URL: <http://trac.sagemath.org/ticket/18282#comment:9>
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/d/optout.
