Deprecate the misuse of symbolic variables as polynomial variable

[simon-king-jena]

Relatively often on sage-support, users run into a problem since they mix symbolics and polynomials. Typically, they do

sage: z = var('z')
sage: P = QQ[z]

and expect that z is the generator of P - which is of course
wrong and will soon mean trouble.

I find even worse that one can do

sage: QQ[x,gap,singular]
Multivariate Polynomial Ring in x, Gap, Singular over Rational Field

since the variable names are obtained from the string representation of the given objects.

It should be clear that the preferred way of constructing a polynomial (or quotient) ring together with its generators is

sage: R.<x,y,z> = QQ[]

Hence, it is quite amazing that in the documentation one occasionally finds the "wrong" usage

sage: x,y,z = var('x y z')
sage: P = QQ[x,y,z]

I suggest to deprecate the possibility of providing the variable names by anything but strings (potentially plus an integer, like PolynomialRing(QQ,'x',5)).

With my patch, one has

sage: QQ[x,gap,singular]
/mnt/local/king/SAGE/sage-4.6/local/bin/sage-ipython:1: DeprecationWarning: (Since Sage Version 4.6.1) Variable name 'x' should be a string, but we obtained <type 'sage.symbolic.expression.Expression'>.
In an interactive session, you should use a definition of the form 'R.<x,y,z>=QQ[]'.
  #!/usr/bin/env python
/mnt/local/king/SAGE/sage-4.6/local/bin/sage-ipython:1: DeprecationWarning: (Since Sage Version 4.6.1) Variable name 'Gap' should be a string, but we obtained <class 'sage.interfaces.gap.Gap'>.
In an interactive session, you should use a definition of the form 'R.<x,y,z>=QQ[]'.
  #!/usr/bin/env python
/mnt/local/king/SAGE/sage-4.6/local/bin/sage-ipython:1: DeprecationWarning: (Since Sage Version 4.6.1) Variable name 'Singular' should be a string, but we obtained <class 'sage.interfaces.singular.Singular'>.
In an interactive session, you should use a definition of the form 'R.<x,y,z>=QQ[]'.
  #!/usr/bin/env python
Multivariate Polynomial Ring in x, Gap, Singular over Rational Field

See also #13187 where the problem of this ticket had the wrong solution (allowing for other types than string).

Depends on #23337
Depends on #23338
Depends on #23343
Depends on #23377
Depends on #23638
Depends on #23640

Component: basic arithmetic

Keywords: deprecation symbolic polynomial variable

Author: Simon King, Ralf Stephan, Jeroen Demeyer

Branch/Commit: public/10483-4 @ 938beb0

Reviewer: Karl-Dieter Crisman, Jeroen Demeyer

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

[simon-king-jena]

Author: Simon King

[simon-king-jena]

comment:1

Attachment: 10483deprecate_symbolics_in_polynomial_rings.patch.gz

Now the patch is attached. By the way: It also adds some doctests...

[kcrisman]

comment:2

Just a question - are the changes in symbolics because before the variables might or might not have been strings?

Also, is there an easy way to show what the generator of P would have been in the "bad" old case? I think that's useful to point out, if one is going to make the remarks in the first place.

[simon-king-jena]

comment:3

Replying to @kcrisman:

Just a question - are the changes in symbolics because before the variables might or might not have been strings?

As much as I know, the changes that I did in symbolics are indeed "replace a variable v by repr(v) when it is used to define a polynomial ring.

Also, is there an easy way to show what the generator of P would have been in the "bad" old case? I think that's useful to point out, if one is going to make the remarks in the first place.

I am not quite sure what you mean. By "remark", you probably mean

In earlier versions of Sage, the names have not necessarily been 
strings. Some users provided a symbolic variable instead of a string, 
and expected that this symbolic variable is the same as the generator 
of the resulting polynomial ring, which is of course not the case. 
This common mistake is now deprecated. 

So, you suggest to write something like this:

In earlier versions of Sage, the names have not necessarily been 
strings. Some users provided a symbolic variable instead of a string, 
and expected that this symbolic variable is the same as the generator 
of the resulting polynomial ring, which is of course not the case.

The following might be surpising for a user expecting the variable `x`
to be a polynomial::

    sage: P = QQ['x'] # here, some users wrote QQ[x], which is now deprecated
    sage: x == P(x)
    x == x
    sage: type(x == P(x))
    <type 'sage.symbolic.expression.Expression'>
    sage: parent(x+P(x)) == P
    False

I am not so convinced that the above text is good. Do you have a better suggesion?

[kcrisman]

Reviewer: Karl-Dieter Crisman

[kcrisman]

comment:4

I'm just saying that the "of course is not the case" is not at all "of course" to me. Current behavior:

sage: P = QQ[x]
sage: P.gen()
x
sage: P.gen() == x
x == x
sage: bool(P.gen() == x)
True
sage: P.gen() is x
False

So unless you think to do the last thing, that is pretty confusing - they have identical representation methods. Which is of course why you want to change this, and introduce the deprecation.

So maybe you could say

... resulting polynomial ring.  However, this was not the case; the generator of a polynomial ring is always a polynomial type, not a symbolic expression, so although they have the same representation, they are not the same.  This explains the following warning:

<deprecation warning doctest

Does that make any sense?

[simon-king-jena]

comment:5

Replying to @kcrisman:

So maybe you could say

... resulting polynomial ring.  However, this was not the case; the generator of a polynomial ring is always a polynomial type, not a symbolic expression, so although they have the same representation, they are not the same.  This explains the following warning:

<deprecation warning doctest

Does that make any sense?

Yes, your formulation sounds much better than mine! Could you make a reviewer patch, changing the formulation?

Best regards, Simon

[kcrisman]

comment:6

Replying to @simon-king-jena:

Replying to @kcrisman:

So maybe you could say

... resulting polynomial ring.  However, this was not the case; the generator of a polynomial ring is always a polynomial type, not a symbolic expression, so although they have the same representation, they are not the same.  This explains the following warning:

<deprecation warning doctest

Does that make any sense?

Yes, your formulation sounds much better than mine! Could you make a reviewer patch, changing the formulation?

Umm... that might not happen for a little while. I can do it, though. But if I'm going to give it a formal review, I have to make sure I check that all those changes involving making things strings really catch what they are supposed to, and I don't have time to do that right now, and then make the reviewer patch, and I am slow on such things... sorry.

Also, I seem to recall there being some discussion about this on sage-devel. It's enough of a change (particularly since there are doctests which use the old one) that it could inconvenience some heavy users to see the deprecation messages, so if you have a link to that discussion I'd be interested in reading through it.

[kcrisman]

comment:7

For reference, here is the sage-devel discussion. Not that much noise, thankfully.