Is this a bug?

[Juan Luis Varona]

In sagemath 7.5, we can use this code:

    t=var('t');

    M=matrix(4,[[0,0,5/4,2],[t,0,0,0],[0,1,0,0],[0,0,1,0]]);

    P=charpoly(M);

    P.substitute(x=1)

Then, we get the correct answer

    -13/4*t + 1

However, the same code gives an error with sagemath 8.2.

A workaround that again gives the correct answer with sagemath 8.2 is the following:

    t=var('t');

    M=matrix(4,[[0,0,5/4,2],[t,0,0,0],[0,1,0,0],[0,0,1,0]]);

    P=charpoly(M);

    y=var('y')

    P.substitute(x=y).substitute(y=1)

    

What is happening?

Is this a bug or a strange feature of the "x" obtained from charpoly?

Thanks in advance!

Juan Luis Varona

[David Joyner]

This works in 7.6 and on cocalc.com:

sage: PR.<x,t> = PolynomialRing(QQ, 2, "x,t")
sage: M=matrix(PR,[[0,0,5/4,2],[t,0,0,0],[0,1,0,0],[0,0,1,0]])
sage: P = M.charpoly()
sage: P(1)
-13/4*t + 1

> Thanks in advance!
>
> Juan Luis Varona
>

> --
> You received this message because you are subscribed to the Google Groups
> "sage-support" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-support...@googlegroups.com.
> To post to this group, send email to sage-s...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-support.
> For more options, visit https://groups.google.com/d/optout.

[Dima Pasechnik]

This appears to be a bug; indeed, in Sage 8.2.beta6 one sees

sage: P.parent()

Univariate Polynomial Ring in x over Symbolic Ring 

(I think it was not the case in 7.5, please check)

but

sage: P.substitute(x=1)

Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in <type 'exceptions.RuntimeError'> ignored

(same error with P(x=1) or with P(1))

[Dima Pasechnik]

This is now https://trac.sagemath.org/ticket/24853

[Juan Luis Varona]

Thanks!

Juan Luis Varona

[Ralf Stephan]

On Tuesday, February 27, 2018 at 10:58:38 AM UTC+1, Dima Pasechnik wrote:

This is now https://trac.sagemath.org/ticket/24853

While that fixes the infinite loop, it only works around another issue that is uncovered, namely that the x in the polynomial returned by charpoly() is not accessible to the user:

sage: P
x^4 - 5/4*t*x - 2*t
sage: P - x^4
x^4 - 5/4*t*x - x^4 - 2*t

The reason is apparently that the polynomial ring was not created by the user on the command line but by the charpoly() code. This shows for example also with:

sage: QQbar(sqrt(2)).minpoly()
x^2 - 2
sage: _ + x^2
x^2 + x^2 - 2

i would consider this a high priority bug. Is there a ticket?

[Simon King]

Hi Ralf,

On 2018-02-28, Ralf Stephan <gtr...@gmail.com> wrote:
> The reason is apparently that the polynomial ring was not created by the
> user on the command line but by the charpoly() code.

The parent of the pre-defined variable x wasn't created by the user
either, so, please don't blame polynomial rings or the
minpoly()/charpoly() code for it.

sage: QQbar(sqrt(2)).minpoly().parent()
Univariate Polynomial Ring in x over Rational Field
sage: x.parent()
Symbolic Ring

> i would consider this a high priority bug. Is there a ticket?

Not in the way you think, IMHO.

One problem that I see is the fact that it is possible to create rings
in which one variable name occurs twice, such as here:
sage: RR['x']['x']
Univariate Polynomial Ring in x over Univariate Polynomial Ring in x
over Real Field with 53 bits of precision
sage: RR['x'].gen()-RR['x']['x'].gen()
-x + x
sage: _==0
False

So, we have two x with different roles. It would make sense to disallow
the creation of such rings.

Also, I belive it is a bug that x is pre-defined as a symbolic variable;
we should finally drop that pseudo-courtesy. Users mistake FAR too often
symbolics with polynomials; by pre-defining x, we let the users believe
that x is good for *all* computations. So, I believe it would be better
to let the user create x him/herself, for the specific application that
he/she has in mind. However, I am aware that I belong to a minority with
that opinion.

Best regards,
Simon

[Dima Pasechnik]

I would be for dropping 'x' as the only "default" variable (defined at start time).

Sage is unique in this sense AFAIK; there are CASes which don't require declaration of any variable, 

there are ones that don't have any special variables like Sage's 'x'.

[Ralf Stephan]

On Wednesday, February 28, 2018 at 9:09:04 AM UTC+1, Dima Pasechnik wrote:

I would be for dropping 'x' as the only "default" variable (defined at start time).

I agree but does it solve the problem I demonstrated. Can you then add x to the minpoly?

[Simon King]

On 2018-02-28, Ralf Stephan <gtr...@gmail.com> wrote:

If you define x as the variable of the minpoly, then certainly you can.

[Ralf Stephan]

Why should I define x when Sage gives me a polynomial with x, doesn't it already know it?

That's what a user would ask and, frankly, s/he would be right.

[John Cremona]

On 28 February 2018 at 13:49, Ralf Stephan <gtr...@gmail.com> wrote:

Why should I define x when Sage gives me a polynomial with x, doesn't it already know it?

That's what a user would ask and, frankly, s/he would be right.

Here is one reason.  In this example:

sage: M=Matrix([[1,2,3],[4,5,6],[7,8,9]])

sage: p = M.charpoly()

sage: p.parent()

Univariate Polynomial Ring in x over Integer Ring

sage: p

x^3 - 15*x^2 - 18*x

sage: x.parent()

Symbolic Ring

when we see the polynomial displayed we see the variable displayed as x, but there has been no assignment to the python variable 'x' behind the scenes.  You are suggesting (it seems) that after computing p here the python variable 'x' should be bound to p.parent().gen().  But it is surely a very Bad Idea for a function to (re)-assign global variables?  This would be a source of many bugs.

It would probably be less confusing if there was no globally defined 'x' at all as has been suggested earlier in this thread.  Then the last line of my example would raise an error, and the documentation could tell users to enter something like 'x = p.parent().gen()' or 'x = p.variables()[0]'   (the latter would be better if a method variable() existed for univariate polynomials!).

John

 

--
You received this message because you are subscribed to the Google Groups "sage-support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscribe@googlegroups.com.

[Ralf Stephan]

It might not be necessary to (re)assign the global variable. Only if the user wants to do operations with the polynomial he wants an x to be that poly variable, and certainly not another x. So, the parser can do the part of figuring out what x is meant, maybe by checking all generator names. Example:

sage: ....charpoly()

x + 1

sage: _ - x

(parser sees underscore and operation, and an unassigned global, so it checks the object referred by the underscore for variable names)

[Ralf Stephan]

Sorry for the noise, it already works fine, just not with characteristic polynomials of symbolic matrices. They messed up my Sage session, so the minpoly example seemed to fail too.

[Justin C. Walker]

> On Feb 28, 2018, at 00:09, Dima Pasechnik <dim...@gmail.com> wrote:
>
> I would be for dropping 'x' as the only "default" variable (defined at start time).
> Sage is unique in this sense AFAIK; there are CASes which don't require declaration of any variable,
> there are ones that don't have any special variables like Sage's 'x’.

I am mildly in favor of dropping this predefinition (FWIW).

Also, for this discussion, one can always access the variable by something like this:
sage: x=P.variables()[0]

Justin

--
Justin C. Walker, Curmudgeon-At-Large, Director
Institute for the Enhancement of the Director's Income
--------
The path of least resistance:
it's not just for electricity any more.
--------

[kcrisman]

I am mildly in favor of dropping this predefinition (FWIW).

Far be it for me to acquire the usual "hobgoblin of little minds" trope, but in this case consistency is probably good.  This argument was had ~10 years ago in great detail, with several hilarious variants implemented one after another.  This has been pretty stable as a reasonable compromise between usability for bored students and the technical needs of the development crew, and I think one of the very nice things about Sage is that for all the learning curve, at least you can "just do math" with it.  Sage cell would not be nearly as useful as Wolfram Alpha without predefined x, for instance.

(Now let the attacks begin ...)

[kcrisman]

> Users mistake FAR too often symbolics with polynomials

Well, of course, and I'm sure rjf would say that Sage developers far too often mistake expressions for functions.  But what percentage of users actually know the difference in any case? (Rhetorical.)

[Dima Pasechnik]

nothing prevents Sagecell from predefining x, or even using Wfram alpha as the backend :-)

[Nils Bruin]

On Wednesday, February 28, 2018 at 8:00:34 AM UTC, Simon King wrote:

So, we have two x with different roles. It would make sense to disallow
the creation of such rings.

-1. It would mean any structure with named generators would have to go dig into the tower that defines it base to check for name clashes. This would make for very unfunctorial code:

Rather than having a construction

R['x'] -> create a univariate polynomial ring in 'x' over the ring R. Here R can be any (commutative) ring.

it would need:

R is an element of the category of commutative rings having none of its generators called 'x'.

I think it makes no sense to build such ridiculous restrictions into the system. The corollary of allowing them is having to deal with generators whose names might be ambiguous in the tower. It's a little unpleasant, but at least explicable, and once one learns how to refer to generators unambiguously, quite doable. These name clashes only happen interactively. On the other hand, name clashes are particularly prone to happen deep in library code, where avoiding them will be very hard.

[Nils Bruin]

I don't think this would be a job for the parser. You'd want x bound to something like "UniversalCoercingNamedGenerator('x')" which would be an object that happily coerces into any parent P via essentially P('x'), but it could do something more fancy.

In order for  1+UniversalCoercingNamedGenerator('x') to work some more magic for finding common covering parents would be necessary. Mind you: you'd end up with a polynomial over ZZ then, not a symbolic expression. For that you'd need

sin(1)+UniversalCoercingNamedGenerator('x')-sin(1)+1

It could be a fun exercise to write such an object, and I think it would be possible. However, I wouldn't be in favour of including it in sage. Its behaviour would be too magical to be reliable for a medium to expert level user, and a novice would probably be able to find all kinds of unexpected edge cases.