Preventing misuse of symbolic variables?

[Simon King]

Hi!

My impression is that relatively often questions on sage-support are
about people accidentally mixing symbolics and polynomials. For
example
sage: z = var('z')
sage: R = QQ[z]
and then believing that z is the generator of R.

I think it would avoid trouble if one would print a big warning
message in those cases.
For example:
sage: z = var('z')
sage: R = QQ[z]
WARNING: The globally defined symbolic expression z is *not* a
generator of Univariate Polynomial Ring in z over Rational Field

I think such warning would be useful.

If you agree, we should think about some details.

* Should the polynomial ring constructor check for any given variable
name whether there is a symbolic variable of that name in globals()?
That might be too slow, and it would be annoying to always get a
warning for ZZ['x'].

* Should the warning only be given when a symbolic variable is passed
as an argument to the polynomial ring constructor? Hence, R=QQ[z]
would trigger the warning, but R.<z>=QQ[] would be without warning,
because here only the string 'z' is passed to the ring constructor. In
that case, the warning might better read "WARNING: The given argument
'z' is a symbolic expression; this is not the same as a generator of
Univariate Polynomial Ring in z over Rational Field".

I am in favour of the second scenario: It would be a quick test and
should prevent some typical misuses.

Best regards,
Simon

[Volker Braun]

The second option sounds better to me.

In any case, it would be very helpful if the error message would explain how to do it correctly, for example:

WARNING: The given argument 'z' is a symbolic expression; this is not the same as a generator of 

Univariate Polynomial Ring in z over Rational Field. Are you trying to say "R.<z>=QQ[]"?

[luisfe]

It would not be more convenient for these cases a FAQ about sage?

I can imagine that, once a user has learned how variables are used,
the user will become annoyed by warnings each time a polynomial ring
is created, even if the warning is only issued once per session.

[Simon King]

Hi Volker,

Sounds good to me.

A related oddity:
sage: PolynomialRing(QQ,[singular],1)
Multivariate Polynomial Ring in Singular over Rational Field

Shouldn't there be at least a warning if the variable names are not
provided as a string but are obtained from repr() applied to the given
argument?

Cheers,
Simon

[Simon King]

Hi Luis!

On 15 Dez., 14:55, luisfe <lftab...@yahoo.es> wrote:
> It would not be more convenient for these cases a FAQ about sage?

Perhaps in addition. How many people read the FAQ *before*
programming?

var("z") produces a "variable", and the generators of a polynomial
ring are also frequently called "variable". I can understand that
people would think it is all the same, and would not expect that they
consult the FAQ on that matter!

> I can imagine that, once a user has learned how variables are used,
> the user will become annoyed by warnings each time a polynomial ring
> is created, even if the warning is only issued once per session.

This is why I suggest the scenario "the ring constructor prints a
warning if the variable name is not a string": QQ[x] or
PolynomialRing(QQ,[singular],1) would result in a warning, but the
*intended* use QQ['x'] or R.<singular>=QQ[] would be OK.

Cheers,
Simon

[Simon King]

Hi all!

On 15 Dez., 15:39, Simon King <simon.k...@uni-jena.de> wrote:
> This is why I suggest the scenario "the ring constructor prints a
> warning if the variable name is not a string": QQ[x] or
> PolynomialRing(QQ,[singular],1) would result in a warning, but the
> *intended* use QQ['x'] or R.<singular>=QQ[] would be OK.

I suggest the deprecation at #10483, ready for review.

Cheers,
Simon

[luisfe]

Hi Simon,

What does it mean 'deprecation'? Will this mean that at some point

sage: var('x')
sage: QQ[x]

will be invalid code?

I am against that change.

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

Is not valid python, it needs the preparser and will not work on a .py
file

sage: QQ['x']

Is just unconfortable when you are creating several rings with
variables with the same names.

If this feature of current sage for creating QQ[x] makes people less
like to try sage, we should find polite ways to tell what is the
expected behavior or use, maybe a warning is ok, but I do not think
that eliminating options in the language is a good option.

Bests,

Luis

[Simon King]

Hi Luis,

On 16 Dez., 20:12, luisfe <lftab...@yahoo.es> wrote:
> What does it mean 'deprecation'? Will this mean that at some point
>
> sage: var('x')
> sage: QQ[x]
>
> will be invalid code?

I think it should be invalid code.

Or, at least PolynomialRing(QQ,[singular]) should be invalid.
Currently, it yields a polynomial ring in variable Singular (upper
case). Similar for gap or any object in Sage whose string
representation can be interpreted as (comma separated list of)
variable names.

> sage: QQ['x']
>
> Is just unconfortable when you are creating several rings with
> variables with the same names.

OK, but in some doc tests one actually finds something like
sage: x,y,z = var('x y z')
sage: P = QQ[x,y,z]

Then,
sage: x,y,z = 'x','y','z'
sage: P = QQ[x,y,z]
is shorter and not less comfortable.

I mean, what's the point of defining a symbolic variable if the only
thing you want to do with it is creating a polynomial ring? Why taking
the risk of accidentally multiplying an element of P with one of these
symbolic variables, ending with something that is *not* in P:
# current behaviour:
sage: x,y,z=var('x y z')
sage: P = QQ[x,y,z]
sage: P.one()*x in P
False

> If this feature of current sage for creating QQ[x] makes people less

> like to try sage, ... I do not think

> that eliminating options in the language is a good option.

If this feature of current sage for creating QQ[x] makes beginners
more likely to create unexpected (for them) results such as "P.one()*x
not in P", therefore frustratedly dropping Sage soon after starting, I
*do* think eliminating that language option is a good option.

Cheers,
Simon