WIP: Formal Power Series

[avichaldayal]

Formal power series implementation using lazy recursion.

[skirpichev]

In [1]: from sympy.series.formal import FormalSeries

In [2]: s1=FormalSeries(x, function=1/(1-x))
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-2-31b2848ac013> in <module>()
----> 1 s1=FormalSeries(x, function=1/(1-x))

/home/sk/src/sympy/sympy/series/formal.py in FormalSeries(x, n, *args, **kwargs)
     49     function = kwargs.pop('function', None)
     50     if function:
---> 51         generator = findgen(x, function, k)
     52 
     53     c, e, k = generator

/home/sk/src/sympy/sympy/series/formal.py in findgen(x, function, k)
    217         diff = function.diff(x, order)
    218         if diff.is_rational_function():
--> 219             return findgen_rational(x, function)  # Integrate k times
    220 
    221     func = Function('f')

TypeError: findgen_rational() takes exactly 3 arguments (2 given)

[skirpichev]

I don't think we should subclass Stream from Expr. The Stream is a container (just like Tuple) to represent a collections.abc.Iterator, maybe we should add also getitem interface too. You should also think about the efficiency. Do we want to recompute Stream again for first 10 terms?

Probably it's also not a right way to implement Stream's arithmetics (e.g. subclass from Expr and override add and so on). But keep going on as-is, lets build something working first, e.g. Stream(sin(x))*Stream(cos(x))...

[skirpichev]

Why you can't use rsolve for all cases?

[avichaldayal]

rsolve cannot solve some cases specially the hypergeometric type.
Ones that are of the form:- P * r(k+m) = Q * r(k)

[skirpichev]

"Some cases" looks like you don't understand well which cases and what's wrong with rsolve.

No doubts - rsolve has algorithms to find solutions for such equations. Do we have a bug with some rsolve_* method or we indeed have a need to implement some new algorighm for rsolve? In the later case - we should improve the recurr module.

[skirpichev]

Ok, I'm not going into the stuff to find generators, ODE's and so on. (Except for few minor remarks.)

1. As I said before, Stream should be a basic container class, just like Tuple. No fancy arithmetic rules.
2. Not sure which interfaces we want to implement for Stream, but at least getitem and iter.
3. Every Basic instance should be rebuildable from its args: self = self.func(*self.args), see test_args.py should also test rebuilability #6426. And arguments should be of the Basic type. This doesn't holds in your case.
4. Python is not a Scheme. You should consider to use generators:

    In [7]: sys.setrecursionlimit(200)
    In [8]: s1 = FormalSeries(x, function=sin(x))
    In [9]: s2 = FormalSeries(x, function=cos(x))
    In [10]: t = s1*s2
    In [12]: for i in xrange(150):
                    t=t.tail
    ...
    RuntimeError: maximum recursion depth exceeded

[avichaldayal]

Stream should be a basic container class, just like Tuple.

Stream now inherits from Basic and acts as a basic container for generator objects. But it still violates the test_args rule. Its argument is a generator object which is not a Basic instance. Sympy should have something to make generators work with its codebase.

[skirpichev]

No, such methods shouldn't be here.

[skirpichev]

why this interface? can't we just use getitem?

[skirpichev]

We can replace last two arguments with r(k) instance (AppliedUndef), like in the rsolve.

[skirpichev]

Lets make something mergeable from this pr.

@avichaldayal, here is some todo:

• First, please try to answer to the PR comments (except from Stream class, see below).
• Then, you should clean up your tiny utillity functions. At least - we shouldn't do arbitrary and unconfigurable restrictions for the output (e.g. the order of ODE and so on).
• As it seems we can't realize an approach, based on lazy streams - lets try FPS representation by formula for coefficients of the series. We have your findgen method for this. We also can implement some arithmetics (at least - addition/substraction, multiplication with the Cauchy product). This shouldn't be too hard.

@certik, @asmeurer - any thoughts?

[leosartaj]

PR is stale. Features proposed already in master. Closing.