sagemath / sage

Main repository of SageMath
https://www.sagemath.org
Other
1.43k stars 479 forks source link

Conversion to `SR` of a multivariate power series creates an expression without variables #34695

Open maxale opened 2 years ago

maxale commented 2 years ago

The following code

R1.<x> = QQ[]
R2.<y,z> = QQ[]
R3.<t> = QQ[[]]
R4.<u,v> = QQ[[]]
V = [x,y,z,t,u,v]
print([SR(q) for q in V])
print([SR(q).variables() for q in V])

prints

x y z 1*t u v
[(x,), (y,), (z,), (t,), (), ()]

That is, conversion SR(t) produces 1*t rather than just t, while conversions SR(u) and SR(v) produce expressions with no variables.

ADDED. The issue with the extra coefficient "1*" is separated to #38545

Component: symbolics

Issue created by migration from https://trac.sagemath.org/ticket/34695

maxale commented 2 years ago

Description changed:

--- 
+++ 
@@ -7,8 +7,8 @@
 R4.<u,v> = QQ[[]]
 print(SR(x), SR(y), SR(z), SR(t), SR(u), SR(v) )

- prints

maxale commented 2 years ago

Description changed:

--- 
+++ 
@@ -5,10 +5,15 @@
 R2.<y,z> = QQ[]
 R3.<t> = QQ[[]]
 R4.<u,v> = QQ[[]]
-print(SR(x), SR(y), SR(z), SR(t), SR(u), SR(v) )
+V = [x,y,z,t,u,v]
+print([SR(q) for q in V])
+print([SR(q).variables() for q in V])

prints

 x y z 1*t u v
+[(x,), (y,), (z,), (t,), (), ()]

+ +That is, conversion SR(t) produces 1*t rather than just t, while conversions SR(u) and SR(v) produce expressions with no variables.

nbruin commented 2 years ago
comment:4

I don't think these are bugs; maybe possibilities for enhancements. You can look at the types:

sage: type(SR(x))
<class 'sage.symbolic.expression.Expression'>
sage: type(SR(t))
<class 'sage.symbolic.expression.SymbolicSeries'>
sage: type(SR(u))
<class 'sage.symbolic.expression.Expression'>
sage: SR(u).pyobject() == u
True

As you can see, univariate series are converted to a different type, which apparently explicitly prints the coefficient, even if it's 1.

From the last line you can see that the multivariate series got wrapped as basically a "constant" in the symbolic ring. This indicates that no more advanced mechanism for converting to SR has been implemented.

For either case, u.polynomial() and t.polynomial() give you a polynomial object that can be converted to SR.

maxale commented 2 years ago
comment:5

At very least I'd expect that under conversion of an algebraic object (polynomial or series) into SR its variables are converted into variables of the resulting symbolic expression. This is not case for multivariate series conversion as the resulting symbolic expression has no variables.

I understand that there are workarounds such as intermediate conversion to a polynomial, but I'd really appreciate if this bug is fixed so no workaround would be needed.

nbruin commented 2 years ago
comment:6

Replying to Max Alekseyev:

At very least I'd expect that under conversion of an algebraic object (polynomial or series) into SR its variables are converted into variables of the resulting symbolic expression. This is not case for multivariate series conversion as the resulting symbolic expression has no variables.

I haven't checked, but there may not be an appropriate multivariate series object in SR to map to. You could just truncate and map that, as "polynomial" does, but that's far from a perfect conversion either. It's definitely worth opening a ticket for implementing a more meaningful conversion there, since mapping them to symbolic atoms is almost surely useless, but I expect that ticket won't be trivial to resolve. Someone would have to study what a reasonable target construction in SR would be.

You could repurpose this ticket for that purpose and perhaps split out improving printing of SymbolicSeries to a separate ticket

maxale commented 2 months ago

You could repurpose this ticket for that purpose and perhaps split out improving printing of SymbolicSeries to a separate ticket

Thank you for the suggestion. I have refocused the current issue to just missing variables in the symbolic expression, while the glitch in printing is now subject to issue #38545.