9 views

Skip to first unread message

Dec 15, 2010, 2:35:57 AM12/15/10

to sage-devel

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

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

Dec 15, 2010, 8:39:17 AM12/15/10

to sage-...@googlegroups.com

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:

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[]"?

Dec 15, 2010, 8:55:21 AM12/15/10

to sage-devel

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.

Dec 15, 2010, 9:09:33 AM12/15/10

to sage-devel

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

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

Dec 15, 2010, 9:39:55 AM12/15/10

to sage-devel

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

On 15 Dez., 14:55, luisfe <lftab...@yahoo.es> wrote:

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

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.

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

Dec 16, 2010, 12:32:56 PM12/16/10

to sage-devel

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

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.

Cheers,

Simon

Dec 16, 2010, 2:12:32 PM12/16/10

to sage-devel

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

Dec 16, 2010, 3:04:33 PM12/16/10

to sage-devel

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

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

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?

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.

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

> 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

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu