make symbolic series subclass of Expression

[rwst]

Making Expression.series create SymbolicSeries (a subclass of Expression) and moving the series code into a separate file series.pyx

• reflects the fact that expressions and series don't commute
• allows upcoming fixes that don't clutter Expression methods with if ex.is_a_series():
• makes for better documentation via having a Symbolic Series ref man page

In refactoring language this is "replace conditional with polymorphism".

#16203, #17400, and #17402 depend on this.

Depends on #19948

Component: symbolics

Author: Ralf Stephan

Branch/Commit: 1832f4a

Reviewer: Vincent Delecroix

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

[rwst]

Branch: u/rws/17659

[rwst]

Commit: a4d2084

[rwst]

New commits:

a4d2084

17659: make symbolic series subclass of Expression

[nbruin]

comment:3

I have nothing invested in how symbolics and series interact, but I see some immediate problems that would arise from subclassing Expression for a Series type:

• when does a SymbolicSeries expression get created? The problem is that the SymbolicRing by itself is a rather untyped environment, so how do you know that an object needs to be made in this specialized class
• How do SymbolicSeries in different variables interact, e.g.:

F = (1/(x+1))*y+sin(x)*y^2+O(y^3)
G = (y/(y^2-2)*x + cos(y)*x^2 +O(x^3)
F+G

Is the result a series? If so, in which variable(s)? One solution would be a SymbolicSeriesRing as a parent, which declares in what variables the series are. I suspect this would be nearly useless for whatever problem the current design tries to solve, though.

[rwst]

comment:4

Nils, this is not about creating a ring but simple refactoring. No behaviour change.

http://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html

Replying to @nbruin:

I have nothing invested in how symbolics and series interact, but I see some immediate problems that would arise from subclassing Expression for a Series type:

These problems already exist, so nothing is new.

[rwst]

Description changed:

--- 
+++ 
@@ -3,3 +3,4 @@
 * allows upcoming fixes that don't clutter `Expression` methods with `if ex.is_a_series():`
 * makes for better documentation via having a `Symbolic Series` ref man page
 
+In refactoring language this is "replace conditional with polymorphism".

[sagetrac-git]

Changed commit from a4d2084 to ed003f0

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

ed003f0

16203: make imports more specific to prevent import loops

[rwst]

Description changed:

--- 
+++ 
@@ -4,3 +4,5 @@
 * makes for better documentation via having a `Symbolic Series` ref man page
 
 In refactoring language this is "replace conditional with polymorphism".
+
+#16302 and #17400 depend on this.

[nbruin]

comment:8

OK, I thought that f.is_series() would do some non-trivial logic to see if f can be used as a series, but it's just exposing a flag that is held internally somewhere. You could indeed expose that information in the type instead, but with ducktyping, subtyping and sage's parent infrastructure doing so might not be as convenient as it might be in systems that are really governed by explicit types. You'd need to think if this refactoring actually will help for further development.

Indeed, being a "series" seems a rather fickle property. It doesn't seem to be preserved under anything:

sage: var('x,y');
sage: f=cos(y).series(y,10)
sage: g=sin(x).series(x,10)
sage: var('x,y');
sage: f=cos(y).series(y,10)
sage: g=sin(x).series(x,10)
sage: f.is_series()
True
sage: (f+f).is_series()
False
sage: (-f).is_series()
False
sage: (f+g).series(x,10)
Order(1)

The last result probably follows from interpreting the Order(x^10) term in g as an order term in y, and hence equivalent to Order(y^0).