Should not allow coercion from polynomials to symbolic ring

[tkluck]

I've been struggling with some unexpected results in my computations with polynomials over the symbolic ring. Eventually, I came to the conclusion that it should not be possible to coerce polynomials to the symbolic ring. (Note: I'm not saying that you can't convert to the symbolic ring!) Here's some reasons for disallowing it.

I've also attached an initial patch implementing this. It needs more work though, because the same thing holds for LaurentSeries and PowerSeries.

Reasons for not allowing PolynomialRing -> SR coercion:

1. This inconsistency:

  sage: R.<t> = QQ[]
  sage: SR(t^2)
  t^2
  sage: R.<t> = SR[]
  sage: SR(t^2)
  Traceback (most recent call last):
  ...
  TypeError: not a constant polynomial

I think the first one should raise a TypeError, too.

2. This one:

  sage: R.<t> = ZZ[]
  sage: (t + 1/2).parent()      # automatic base extension
  Univariate Polynomial Ring in t over Rational Field
  sage: R.<t> = ZZ[]
  sage: (t + pi).parent()   # expect base extension SR[t]
  Symbolic Ring

It is not hard to imagine that this gives all kinds of unexpected results when trying to manipulate these kind of rings programmatically. This must have cost me days and days.

3. There is also a better way to convert a polynomial to the symbolic ring,
   namely just substituting a symbolic variable:

sage: R.<t> = PolynomialRing(ZZ,'t')
sage: f = t^2 - t
sage: t = var('t')
sage: f(t)
(t - 1)*t
sage: f(t).parent()
Symbolic Ring

This has the advantage that the conversion is explicit.

4. Philosophically, I would say that the name of the variable is just a display label, but as it is, it has the side effect of determining what variable to coerce to. Then if you want to return a polynomial from a library routine, you can't be sure that it won't collide with a user-defined variable upon coercion.

Component: algebra

Work Issues: address review

Issue created by migration from https://trac.sagemath.org/ticket/13360

[tkluck]

Attachment: trac_13360_no_coercion_from_polynomials_to_expressions.patch.gz

Attachment: trac_13360_no_coercion_from_polynomials_to_expressions_002.patch.gz

[tkluck]

Description changed:

--- 
+++ 
@@ -35,7 +35,7 @@
 namely just substituting a symbolic variable:
 
 ```
-  sage: R = PolynomialRing(ZZ,'t')
+  sage: R.<t> = PolynomialRing(ZZ,'t')
   sage: f = t^2 - t
   sage: t = var('t')
   sage: f(t)

[nbruin]

comment:3

3. You probably agree that conversion from polynomial rings to SR should be possible. However, I'm afraid that requires coercion to easily work in the following example:

A.<a>=QQ[]
B.<b>=A[]
f=a^2*b+a*b^2
SR(f)

Even though there is an explicit conversion asked, I think the system uses coercion on the coefficients of f, which are elements of the polynomial ring A. The same thing applies even more essentially to evaluating f at a symbolic expression.

f(SR('x'))

It's always one level further down where coercions are really useful.

For your other examples:

1), 2) SR[]

That should really be an error already. Nothing useful will even come from defining polynomials over the symbolic ring.

[EDIT: As shown below, people DO find uses for them.]

SR is not a fully implemented ring. For instance, equality testing is spotty at best. It's not really an integral domain either:

max_symbolic(x,0)*min_symbolic(x,0)

4. To some degree I agree with your philosophy, but Sage's coercion system doesn't. The variable names are part of the identity, e.q. QQ['x'] and QQ['x'] are identical objects, but QQ['x'] and QQ['y'] aren't (they aren't even equal). Similarly, elements from QQ['x'] coerce into QQ['x','y'] but not into QQ['a','b']. Coercing by name into SR is completely in step with that, whatever collisions that causes.
   It may be possible to override this behaviour by installing custom coercions.

[tkluck]

comment:4

Replying to @nbruin:

3. You probably agree that conversion from polynomial rings to SR should be possible.

Thanks for commenting, nbruin! Yes I agree (I actually mention that in italics right at the top).

However, I'm afraid that requires coercion to easily work in the following example:

A.<a>=QQ[]
B.<b>=A[]
f=a^2*b+a*b^2
SR(f)

I would suggest replacing this with

sage: a,b=var('a,b')
sage: f(a,b)

Which relates to ...

Even though there is an explicit conversion asked, I think the system uses coercion on the coefficients of f, which are elements of the polynomial ring A. The same thing applies even more essentially to evaluating f at a symbolic expression.

f(SR('x'))

I'm glad you mention this example. For me, this is not the same thing. In a way, it is exactly the distinction I'm trying to make with this ticket. I think your example should be allowed whereas coercion shouldn't.

For your other examples:

1), 2) SR[]

That should really be an error already. Nothing useful will even come from defining polynomials over the symbolic ring.

The sage documentation explicitly states that this is supported (at least in the case of the PowerSeriesRing).

As for it not being useful, I strongly disagree with that. As soon as you need coefficients like pi or sin(3), this is the only way to go. For example, to come back to your code:

sage: A.<a>=QQ[]
sage: B.<b>=A[]
sage: f=a^2*b+a*b^2
sage: f(b=pi)      # would expect an expansion in a, like pi*a^2 + pi^2*a
(pi*a = a^2)*pi
sage: f(b=pi).parent()   # I would expect: SR[a]
Symbolic Ring

Or, for a more specialized example: I'm doing calculations with Lax matrices in integrable systems. Then you want to calculate Laurent series in the spectral parameter, whereas all other variables are manipulated symbolically (i.e. functions can be applied to them). Just doing those calculations in the symbolic ring is much slower, you would need to collect and expand all the time, and the symbolic ring cannot keep track of big ohs.

Of course, this ticket is exactly about inconsistencies arising from polynomial rings over SR. If you believe those should raise an error already, than it is logical to say that that is the source of the inconsistency. If, like me, you believe that it is very useful, then you open a ticket like this one. :-)

4. To some degree I agree with your philosophy, but Sage's coercion system doesn't. The variable names are part of the identity, e.q. QQ['x'] and QQ['x'] are identical objects, but QQ['x'] and QQ['y'] aren't (they aren't even equal). Similarly, elements from QQ['x'] coerce into QQ['x','y'] but not into QQ['a','b']. Coercing by name into SR is completely in step with that, whatever collisions that causes.

I think this is unfortunate, but I agree that the philosophy is in line with this.

[tkluck]

comment:5

4. To some degree I agree with your philosophy, but Sage's coercion system doesn't. The variable names are part of the identity, e.q. QQ['x'] and QQ['x'] are identical objects, but QQ['x'] and QQ['y'] aren't (they aren't even equal). Similarly, elements from QQ['x'] coerce into QQ['x','y'] but not into QQ['a','b']. Coercing by name into SR is completely in step with that, whatever collisions that causes.

I think this is unfortunate, but I agree that the philosophy is in line with this.

As an afterthought: the symbolic ring offers SR.symbol() which guarantees a unique variable that doesn't clash with user-defined ones. There's no such thing for polynomial rings. On the other hand, you could make your library code accept a variable name in its argument spec. Then it's the user's responsibility to prevent a name clash.

[nbruin]

comment:6

OK, you seem to have some use cases where polynomials over SR do have some use. Indeed, basic arithmetic (but not division!) should be OK. I think what you need is that elements from polynomial rings over SR are not coercible into SR. A solution like this would need an expert in the coercion system to implement correctly, because the coercion system is one area of sage where a small and seemingly innocuous change can easily have huge consequences (for performance, correctness or both) for the entire system.

Roughly: if R.coerce_map_from(SR) is not None then SR.coerce_map_from(R['a',...]) should be None. I think that would remove most of the unexpected results.

[novoselt]

comment:7

Polynomials with coefficients in SR are very useful and it is a pity that their support is not ideal - hopefully it will improve.

I do not agree that construction in 1) should give errors: as it is written, it is explicit conversion of a polynomial to the symbolic ring and I was annoyed by TypeError: not a constant polynomial recently, having to write SR(str(f)).

[nbruin]

comment:8

Replying to @novoselt:

I do not agree that construction in 1) should give errors: as it is written, it is explicit conversion of a polynomial to the symbolic ring and I was annoyed by TypeError: not a constant polynomial recently, having to write SR(str(f)).

How about

R=SR['t']
f=SR('t') * R.0

It's much better if SR(f) gives an error for that. The error you're seeing is the failure of a non-constant polynomial to be converted to an element of its base ring, as expected. Really, what you're looking for is a "specialization" of your polynomial, effected by an evaluation:

f(SR('t'))

No reason to convert to strings.

Polynomial rings should really not be coercible to their base rings, and probably also not generally convertible to them (apart from constants). Sage's concept of coercion really relies on there not being "loops" in the coercion graph. They wreak havoc with finding common covering structures.

[novoselt]

comment:9

I think it is completely unambiguous what do I mean by SR(f) if f is a polynomial - I want a symbolic expression equal to this polynomial with the same names for variables. It is an explicit call to perform a conversion, not a coercion. If it is necessary to handle this conversion separately, it should be done internally, transparent for the user.

f(SR('t')) is unintuitive and what am I supposed to do if I have a hundred variables in my polynomial ring? Cook up some dictionary substitution for evaluation which will be even less intuitive? I don't see how it would be better than SR(str(f)), and the best form would be SR(f).

I understand that loopy rings may cause difficulties in the framework, yet it is not a reason to cripple the symbolic ring. I think that pretty much anything has to be convertible to it. A possible solution for the situation in question may be "symbolic ring with black-listed names", so that if I want to consider a polynomial ring in t with symbolic coefficients, I explicitly create "SR that will never use t". Or perhaps a white-list version "SR that can only use {a, d, beta} for variable names" is better, especially if one creates iterated polynomial rings. Then there will be no collision between base ring and SR and clearly all such restricted rings are canonically coercible to SR, but not back. Note that such rings will also allow unambiguous conversion to polynomial rings with symbolic coefficients.