Opened 4 years ago

Last modified 4 years ago

#20091 new defect

.extension with other variables than x

Reported by: dkrenn Owned by:
Priority: major Milestone: sage-7.1
Component: algebra Keywords:
Cc: Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description

T.<t> = ZZ.extension(x^2-x+2)

works, where

sage: x.parent()
Symbolic Ring

But

sage: X = SR('x')
sage: T.<t> = ZZ.extension(X^2-X+2)

does not work:

ValueError: each generator must be integral

It should work with any symbolic variable; error message does not give a hint what is wrong.

Change History (1)

comment:1 Changed 4 years ago by nbruin

OK, the problem is this code in EquationOrder?:

    R = ZZ['x']
    ...
        try:
            R(f)
        except TypeError:
            raise ValueError('each generator must be integral')

So indeed x is singled out. Naturally, the constructor should work with any univariate polynomial over ZZ and it does because of the conversion rules:

sage: ZZ['x'](ZZ['c'].0)
x
sage: ZZ['x'](QQ['c'].0) #univariate converts generator to generator (good choice?)
x
sage: ZZ['x'](QQ['x,v'].0) #name matches
x

but already for univariate polynomials that are not explicitly defined as such things go wrong:

sage: ZZ['x'](QQ['u,v'].0) #no conversion at all
TypeError:

(yes, an empty error message)

sage: ZZ['x'](QQ['u,x'].0) #u doesn't convert into ZZ['x']
TypeError: cannot coerce nonconstant polynomial

The behaviour with "SR" is consistent with this. However, x shouldn't really have a special role here. How far do we want to go with trying to read f as a univariate polynomial over ZZ? Do we want to special case all kinds of rings (multivariate, SR, etc.) to specially see if, even if there are more generators on the ring, really only one is occurring in f, so we can read it as a univariate polynomial?

The "see if we can convert into ZZ['x']" is really a bit of a poor substitute for what we would really want to do. Input should really be "a univariate polynomial over ZZ", and as such input from SR would be not valid. But that would be impractical.

Note: See TracTickets for help on using tickets.