monomials() and lt() for expansions of SymmetricFunctions over SymbolicRing broken

[schilly]

smc user reported these inconsistencies related to listing monomials of a symmetric function:

e = SymmetricFunctions(SR).e()
f = e([2]).expand(3)
f
f.monomials()
f.lt()

x0*x1 + x0*x2 + x1*x2
[1]
x0*x1 + x0*x2 + x1*x2

i.e. just [1] and the whole polynomial, while over QQ:

e = SymmetricFunctions(QQ).e()
f = e([2]).expand(3)
f
f.monomials()
f.lt()

x0*x1 + x0*x2 + x1*x2
[x0*x1, x0*x2, x1*x2]
x0*x1

lists all three monomials and only one term for lt().

[dimpase]

Most probably SymmetricFunctions should not allow SR as an argument. By right,

e = SymmetricFunctions(SR).e()
f = e([2]).expand(3)

should create f in SR, but it does something totally different:

sage: type(f)
<class 'sage.rings.polynomial.multi_polynomial_element.MPolynomial_polydict'>

However it is possible to convert f into a symbolic expression:

sage: ff=SR(f)
sage: type(ff)
<type 'sage.symbolic.expression.Expression'>
sage: ff.operands()
[x0*x1, x0*x2, x1*x2]

So the latter might be used as a workaround...

[dimpase]

Nicolas, do you know who can comment on this, what would be a way to resolve this?

[tscrim]

This is actually not a problem with symmetric functions, but how coercion into a polynomial ring over SR works:

sage: R.<x,y,z> = PolynomialRing(ZZ)
sage: p = x + y
sage: S.<x,y,z> = PolynomialRing(SR)
sage: f = S(p); f  # This is what is used in symmetric functions in expand()
x + y
sage: f.monomials()
[1]
sage: f.coefficients()
[x + y]
sage: S.coerce_map_from(R)(p).monomials()
[1]
sage: S.coerce_map_from(R)
Composite map:
  From: Multivariate Polynomial Ring in x, y, z over Integer Ring
  To:   Multivariate Polynomial Ring in x, y, z over Symbolic Ring
  Defn:   Conversion via _symbolic_ method map:
          From: Multivariate Polynomial Ring in x, y, z over Integer Ring
          To:   Symbolic Ring
        then
          Generic morphism:
          From: Symbolic Ring
          To:   Multivariate Polynomial Ring in x, y, z over Symbolic Ring

We probably check to see if the input can be considered a coefficient first, then try variable to variable. I would think the latter is actually a faster check, but it is probably a lesser-used code path.

[dimpase]

Replying to tscrim:

This is actually not a problem with symmetric functions, but how coercion into a polynomial ring over SR works:

[...]

We probably check to see if the input can be considered a coefficient first, then try variable to variable. I would think the latter is actually a faster check, but it is probably a lesser-used code path.

To me this all sounds strange. Shouldn't a polynomial ring over SR be in SR itself, or it least it should be possible to coerse it there? But one gets:

sage: S.<x,y,z> = PolynomialRing(SR)
sage: p=x+y
sage: p in SR
False
sage: SR(p)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
[...]
TypeError: not a constant polynomial
sage: 

[rws]

See also #20454.