Dear all,
> 2. When doing some test for the above problem I realize that
*R.<x>=PolynomialRing(QQ,order='neglex')
> *does not take into account the order (the above *f* is not a
unit).
Yes, it is, since the ring is in fact localised.
> This is not really an issue, the problem is the fact that the
function
> accept the entry *order* but it ignores it silently.
Ahm, why do you think it is ignored?
I have rechecked that
*R.<t>=PolynomialRing(QQ,order='neglex');(1+t).is_unit()* yields False
My impression is that Enrique is right: in the constructor
PolynomialRing, for univariate polynomial rings the argument `order`
seem indeed to be ignored: see
`sage/src/rings/polynomial/polynomial_ring_constructor.py` at line 465,
the function called in this case is `_single_variate` that does not have
an `order` argument. Or to state it otherwise, we have
sage: R.<t>=PolynomialRing(QQ,order='neglex')
sage: R.parent()
<class
'sage.rings.polynomial.polynomial_ring.PolynomialRing_field_with_category'>
And `PolynomialRing`s are *univariate* polynomial rings, without an
order argument.
A possibility could be to define a *multivariate* polynomial ring in
just one variable (!) when an `order` is given. This is possible with
the current implementation I think, though the results do not seem to be
correct for the particular question of whether (1+t) is a unit:
sage: from sage.rings.polynomial.multi_polynomial_ring import
MPolynomialRing_polydict
sage: R = MPolynomialRing_polydict(QQ, 1, ('t',), "neglex"); R
Multivariate Polynomial Ring in t over Rational Field
sage: R.inject_variables()
Defining t
sage: (1+t).is_unit()
False
Best,
Bruno
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.