Opened 6 years ago

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

Reported by: Owned by: schilly major sage-7.3 symbolics nthiery N/A

### Description

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

```e = SymmetricFunctions(SR).e()
f = e().expand(3)
f
f.monomials()
f.lt()

x0*x1 + x0*x2 + x1*x2

x0*x1 + x0*x2 + x1*x2
```

i.e. just `` and the whole polynomial, while over `QQ`:

```e = SymmetricFunctions(QQ).e()
f = e().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()`.

### comment:1 Changed 6 years ago by dimpase

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

```e = SymmetricFunctions(SR).e()
f = e().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...

### comment:2 Changed 6 years ago by dimpase

• Summary changed from monomials() and lt() for SymmetricFunctions over SymbolicRing broken to monomials() and lt() for expansions of SymmetricFunctions over SymbolicRing broken

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

### comment:3 follow-up: ↓ 4 Changed 6 years ago by 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()

sage: f.coefficients()
[x + y]
sage: S.coerce_map_from(R)(p).monomials()

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.

Last edited 6 years ago by tscrim (previous) (diff)

### comment:4 in reply to: ↑ 3 Changed 6 years ago by dimpase

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:
```