#9944: categories for polynomial rings
--------------------------------------------+-------------------------------
Reporter: robertwb | Owner: nthiery
Type: defect | Status: needs_review
Priority: major | Milestone: sage-4.7.1
Component: categories | Resolution:
Keywords: | Work_issues:
Upstream: N/A | Reviewer: Nicolas M.
Thiéry, Mike Hansen, Martin Raum
Author: Robert Bradshaw, Simon King | Merged:
Dependencies: sage-4.7 + #11139 |
--------------------------------------------+-------------------------------
Comment(by SimonKing):
Replying to [comment:70 mraum]:
> Simon, you are completely right about the doctest with span. Could we
add #indirect doctest so that attention is drawn to this?
OK, and perhaps I even add a comment like "The method zero() calls this
hom space with a function, not with a matrix, and that case had previously
not been taken care of".
> Some issues, that I encountered:
> in polynomial_element.pxy new line 5352 : what about p-adics? I haven't
had the time to check, but perhaps you can already say something about it.
You mean the fact that I return `<Polynomial>self._parent(self[:n])` when
it previously was `<Polynomial>self._parent(self[:n], check=False)`?
I tried to reconstruct what made me do that change. It now seems to me
that it was not because of a bug but because I thought `self[:n]` would
return a truncated list of coefficients, which apparently is not the case
(at least not always).
Anyway. ''If'' you feed a truncated list of coefficients into the element
constructor of a univariate polynomial ring, and if you give
`check=False`, then you could create a polynomial whose list of
coefficients ends with a zero. That is a problem for non-padic
polynomials, since `valuation()` and other methods will result in an
error.
So, `if` there are polynomials p so that `p[:n]` returns the list of the
first n coefficients, then `check=False` is a bug.
However, if `p[:n]` returns a polynomial that actually has the right
parent, then the argument `check` will not be tested at all. So, `False`
or `True` does not matter.
'''Conclusion:''' Removing `check=True` should have no influence on
performance, but may fix a potential problem (depending on the behaviour
of `p[:n]`).
In any case, it can not be a problem for padics, even ''if'' `self[:n]`
returns a list: I do not remove trailing zeroes from the coefficient list,
but simply let the element constructor of `self._parent` decide what to do
-- and the element constructor of padic and non-padic polynomial rings
will do the right thing.
Here is a padic example:
{{{
sage: P.<x> = Zp(5)[]
sage: p = x^4
sage: p.truncate(3).valuation()
+Infinity
}}}
and that is because `p[:3].parent() is P`.
I just found that the existing test for the `truncate` method in
`sage.rings.polynomial.polynomial_element` does ''not'' test that method.
Namely:
{{{
sage: R.<x> = ZZ[]; S.<y> = R[]
sage: f = y^3 + x*y -3*x
sage: from sage.misc.sageinspect import sage_getfile, sage_getsourcelines
sage: sage_getfile(f.truncate)
'/mnt/local/king/SAGE/sage-4.7.alpha5/devel/sage/sage/rings/polynomial/polynomial_element.pyx'
sage: sage_getsourcelines(f.truncate)[1]
6000
}}}
So, `f.truncate` is a different truncate method. I'll change that doctest
by making S a sparse polynomial ring:
{{{
sage: R.<x> = ZZ[]; S.<y> = PolynomialRing(R, sparse=True)
sage: f = y^3 + x*y -3*x
sage: sage_getfile(f.truncate)
'/mnt/local/king/SAGE/sage-4.7.alpha5/devel/sage/sage/rings/polynomial/polynomial_element.pyx'
sage: sage_getsourcelines(f.truncate)[1]
5335
}}}
> in polynomial_element.pxy new line 6180ff : there are two returns that
do not belong there
Yep. See post 60. I promised to remove the lines starting with the comment
`# this is likely to be overridden below:` in the final patch version, but
wanted to wait for input of a reviewer (thank you, reviewer!)
> in polynomial_real_mpfr_dense.pxy new line 57: Do you mean [0]?
Yes, and I'm changing it, although `i` works as well:
{{{
sage: from sage.rings.polynomial.polynomial_real_mpfr_dense import
PolynomialRealDense
sage: PolynomialRealDense(RR['x'],None)
0
}}}
> in polynomial_ring.py new line 468 : The coercing is the other way
around.
Thank you!
> Please don't forget to check the rejects that I've mentioned above. This
could be a real problem for Jeroen.
I'll try it, and will soon submit a new version of the last patch.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9944#comment:72>
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.
