Opened 5 months ago

# No order for univariate polynomial rings

Reported by: Owned by: bruno major sage-9.1 algebra polynomial, order tmonteil Bruno Grenet N/A u/bruno/univariate_polyring_order

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.

### comment:1 Changed 5 months ago by bruno

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

### comment:2 Changed 5 months ago by bruno

• Description modified (diff)

### comment:3 Changed 5 months ago by bruno

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 months 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?

### comment:5 Changed 3 weeks ago by embray

• Milestone changed from sage-8.9 to sage-9.1

Ticket retargeted after milestone closed

Note: See TracTickets for help on using tickets.