Opened 7 weeks ago

Last modified 4 weeks ago

#28420 new enhancement

No order for univariate polynomial rings

Reported by: bruno Owned by:
Priority: major Milestone: sage-8.9
Component: algebra Keywords: polynomial, order
Cc: tmonteil Merged in:
Authors: Bruno Grenet Reviewers:
Report Upstream: N/A Work issues:
Branch: u/bruno/univariate_polyring_order Commit:
Dependencies: Stopgaps:

Description (last modified by bruno)

This ticket add an error message for the constructor of polynomial ring when trying to build a univariate polynomial ring with a term order. Currently, order = ... is silently ignored for univariate polynomial rings and this leads to confusions for some users, cf this Ask question¹.

Before:

sage: PolynomialRing(QQ, 'x', order = TermOrder('wdegrevlex', (2,)))
Univariate Polynomial Ring in x over Rational Field

After:

sage: PolynomialRing(QQ, 'x', order = TermOrder('wdegrevlex', (2,)))
Traceback (most recent call last):
...
TypeError: univariate polynomial rings do not accept an order. Use a 1-variable multivariate polynomial ring instead. 

¹ The Ask question uncovers two distinct problems, the second one is fixed in #28421.

Change History (4)

comment:1 Changed 7 weeks ago by bruno

  • Branch set to u/bruno/univariate_polyring_order
  • Description modified (diff)
  • Keywords order added
  • Summary changed from Error messages for polynomial ring constructor to No order for univariate polynomial rings

comment:2 Changed 7 weeks ago by bruno

  • Description modified (diff)

comment:3 Changed 7 weeks ago by bruno

  • Cc tmonteil added

Actually, I've trouble with my proposed solution. I actually tried two possibilities, but with difficulties in both cases:

  1. The solution currently in description: Constructing a univariate polynomial ring with an order in paramater throws an Exception;
  2. Do not throw an Exception, rather make PolynomialRing(R, 'x', order = ...) behave like PolynomialRing(R, 1, 'x', order = ...), that is return a 1-variable multivariate polynomial ring.

In the first case I have a lot of doctests failing, I've not investigated all of them yet. The second solution has much less failed doctests. Though I have mainly one, that actually also occurs with the first solution.

The problem is as follows: To discover that there is a coercion from R['x,y'] to Frac(R['x'])['y'], the algorithm checks whether there is a coercion from R['x,y'].remove_var('y') to Frac(R['x']). A problem occurs in the two solutions, because R['x,y'].remove_var('y') attempts to build the polynomial ring R['x'] but passes the order parameter.

  1. With the first solution, an Exception is raised.
  2. With the second solution, a 1-variable multivariate ring is built, but it happens that there is no coercion from the multivariate R['x'] to the fraction field of the univariate R['x'].

The simplest(?) workaround I've in mind is to keep with the second solution and to add the missing coercion (note: I don't know how to do that!). But I am not sure that this is the right thing to do. In particular, this implies that remove_var now returns a 1-variable multivariate polynomial ring instead of a univariate polynomial ring.

  1. The pro: It makes sense for weighted term orders since the 1-variable multivariate ring keeps the weight of the remaining variable;
  2. The con: Users may be surprised by R['x,y'].remove_var('y') not to return a (truly) univariate ring.

comment:4 Changed 4 weeks ago by mmezzarobba

Would it be hard to check if the term order is weighted, and return a multivariate ring in a single variable or a univariate ring depending on that?

Note: See TracTickets for help on using tickets.