On Saturday, October 29, 2016 at 12:55:51 AM UTC-7, Ralf Stephan wrote: > > Hello, > > TLDR: > Proposal is to support the precision as argument to ex.series() instead of > the order > term exponent. Visible changes only expected with Laurent series. >
I think we support these properties (on both univariate and multivariate power series rings and laurent series fields) already in the form of precision_absolute and precision_relative. For p-adic rings we have two different rounding modes: "capped-rel", which ensures an upper bound on the relative precision (the number of terms capped track of) and "capped-abs", which bounds the order of the error term. If we're finding power series/laurent series arithmetic would benefit from having these two, perhaps we should equip them with the same "type" choice. If ex.series(...) knows in which ring it needs to return its answer, it knows how many terms to compute once it has the first non-zero term. So I think ex.series(...) just needs arguments that specify the type of power series ring it needs to land in (If we follow p-adics, a "type=..." argument makes most sense. You could provide further alternative arguments that may be more intuitive to the casual user) So perhaps you'd get: sage: sin(x).series(x,5,type="capped-abs") 1*x + (-1/6)*x^3 + Order(x^5) sage: sin(x).series(x,5,type="capped-rel") 1*x + (-1/6)*x^3 + 1/120*x^5 + Order(x^6) Aside: For power series rings, it looks like we also allow for "infinite precision" elements. It's a bit of a toss-up how they should behave: e.g., if one multiplies two, one could produce an infinite precision element again (that's what happens now), with the penalty that the result blows up. Or one could enforce the precision bound. e.g., computing R.<x>=PowerSeriesRing(QQ) (1+x+O(x^20))^10000 is very quick; without the O(x^20) term this takes quite long (because currently sage does just a polynomial computation) Long version: > > There are two fundamentally different methods to compute series expansions > of > symbolic expressions: differentiation (GiNaC, Pynac, SymPy) and, for a > subset > of expressions, combinations of inverse, reverse, and other tricks applied > to > ring series (Pari, Flint). Pro/Con: > > differentiaton: slow but general > ring series: fast but can only handle univariate and a subset of functions > > So it makes sense to speed up the first in case there are only suitable > functions > involved. However, with ring series a fixed precision is applied which is > not the > same as the exponent of the order term because series can shift left by > division > through x (Laurent series) which shifts the order term as well. OTOH the > Sage > ex.series argument prec defines the final order term (as does SymPy with > n, but > they don't use ring series yet). > > To be able to apply both methods with the same interface it seems > necessary to > not set an order term exponent in the series command but the precision. > -- You received this message because you are subscribed to the Google Groups "sage-devel" 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
