I definitely agree that Series infrastructure is important and SymPy should have it.
Maybe the base class can be just a pure interface (in Java terms, pure virtual functions in C++), not requiring actual storage sparse or dense. So that coefficients can be retrieved through a function. Then in Sparse or Dense subclass coefficients can be cached or pre-calculated in the appropriate manner. Other nice to have series also supported in the new structure would be Fourier trigonometric series: - SUM( an*sin(n*x)+bn*cos (n*x) ) - SUM( cn*exp(i*n*x) ) And thinking even more general any projection on a Hilbert space with a given base of functions (of which particular cases are Fourier series, Legendre polynomial series, etc.). Pablo. On Thursday, November 28, 2013 5:39:30 AM UTC+1, Ondřej Čertík wrote: > > On Tue, Nov 26, 2013 at 5:38 AM, mario <[email protected] <javascript:>> > wrote: > > > > In PR 609 and PR 2630 power series are implemented with dictionaries, > that > > is in a sparse representation. > > The sparse representation is efficient when there are many variables. PR > > 2630 uses ``ring()``. > > > > For power series in one variable the dense representation is usually > faster. > > In `compose_add` in PR 2630 series in one variable are used, so using > the > > dense representation > > would be faster, but in a negligible way, since `compose_add` takes > roughly > > 5% of the time in `minpoly`. > > > > In PR 609 there is lpoly.py, which deals with power series, and > ltaylor.py. > > lpoly.py can now be implemented using ``ring()``; this is partially done > in > > ring_series.py in PR 2630, > > where there are only the functions used in the computed sum. It seems to > me > > that ring_series.py fits > > well in SymPy; if one wants to compute efficiently power series, > > one can use ``ring`` with ring_series.py functions (once all the series > > functions in lpoly.py are ported). > > > > To do a thorough treatment of power series, one should also implement > > the dense representation; consider the case of Laurent series; > > add functions to manipulate series at a higher level, possibly using a > > Series class with an Order function. > > > > Mateusz Paprocki might want to comment on this. > > > > PowerSeriesRing in Sage could be an example of higher level > representation. > > Thanks a lot for the feedback. So I think we should try to merge your > code, or improve it, so that it can be merged. > > > > ltaylor.py uses lpoly.py to compute the taylor series of SymPy > functions; > > if the function is not smooth enough, the computation is passed to > > series.series. > > So if the function is smooth enough, the taylor series is computed fast > > (more or less the speed of `taylor` in Sage); otherwise it can be > > slightly slower than series.series. > > I do not know if it is a good approach; anyway, since it uses power > series, > > for the moment I will leave it aside. > > Btw, just today I discovered a real life example where series() is really > slow: > > https://github.com/sympy/sympy/issues/2635 > > Ondrej > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
