Taylor series and asymptotic expansions
Ronan Lamy
about Taylor series and the like has been the lack of a common and
unambiguous vocabulary. So, I've started a wiki page defining some
concepts in order to clarify things:
https://github.com/sympy/sympy/wiki/Function-expansions
Feel free to expand or amend it, add links to and from it, etc.
NB: I had to use Markdown syntax because I couldn't figure out how to
get LaTeX to work in rST.
Also while writing it, I've noticed 2 additional problems with
Expr.series:
* The order is off by one.
* Its name is misleading since it doesn't return a series.
Chris Smith
>> Also while writing it, I've noticed 2 additional problems with
>> Expr.series:
>> * The order is off by one.
>> * Its name is misleading since it doesn't return a series.
Can you give examples? In 2084 I get:
>>> cos(x).series(n=3)
1 - x**2/2 + O(x**3)
terms valid up TO n=3 are returned (which is consistent with sympy range behavior).
What do you call the thing that is being returned? Is this what you refer to as an "asymptotic expansion"?
/c
/c
Ronan Lamy
> Ronan Lamy wrote:
> >> Also while writing it, I've noticed 2 additional problems with
> >> Expr.series:
> >> * The order is off by one.
> >> * Its name is misleading since it doesn't return a series.
>
> Can you give examples? In 2084 I get:
>
> >>> cos(x).series(n=3)
> 1 - x**2/2 + O(x**3)
>
> terms valid up TO n=3 are returned (which is consistent with sympy
> range behavior).
The conventional definition of the order of the expansion is that it's
the degree of the last term included in the polynomial approximation, so
one less than the order of the excluded terms. Your example is a
second-order expansion, because it gives a second-order approximation.
Our definition might be more convenient, but it's not the usual one.
Maybe this is just a documentation issue.
>
> What do you call the thing that is being returned? Is this what you
> refer to as an "asymptotic expansion"?
I call anything with a O() in it an asymptotic expansion, but this is
more precisely the 2nd-order Taylor expansion of cos(x).
Chris Smith
> Le mercredi 23 février 2011 à 09:40 +0545, Chris Smith a écrit :
>> Ronan Lamy wrote:
>>>> Also while writing it, I've noticed 2 additional problems with
>>>> Expr.series:
>>>> * The order is off by one.
>>>> * Its name is misleading since it doesn't return a series.
>>
>> Can you give examples? In 2084 I get:
>>
>> >>> cos(x).series(n=3)
>> 1 - x**2/2 + O(x**3)
>>
>> terms valid up TO n=3 are returned (which is consistent with sympy
>> range behavior).
>
> The conventional definition of the order of the expansion is that it's
> the degree of the last term included in the polynomial approximation,
> so
> one less than the order of the excluded terms. Your example is a
> second-order expansion, because it gives a second-order approximation.
>
The documentation has been updated to reflect that terms up to O(x**n) are returned.
> Our definition might be more convenient, but it's not the usual one.
> Maybe this is just a documentation issue.
Til now we have lived with terms refering to factors in a Mul and factors refering to terms in an Add...do we need to change the name from series to something else or should we just update the docstring?
/c
Alexander Eberspächer
On Wednesday, February 23, 2011 5:25:45 AM UTC+1, Ronan Lamy wrote:
The conventional definition of the order of the expansion is that it's
the degree of the last term included in the polynomial approximation, so
one less than the order of the excluded terms. Your example is a
second-order expansion, because it gives a second-order approximation.
f(x) = 1 - 0.5 x^2 + O(4).
Note the O(4) term. I think this is usually done to reflect the fact that in this expansion cannot contain uneven powers of x as cos(x) is an even function. Though competitors such as Mathematica are not that smart, I think a behaviour like this might be worth considering.
Cheers
Alex
Ondrej Certik
On Tue, Feb 22, 2011 at 7:12 PM, Ronan Lamy <ronan...@gmail.com> wrote:
> I think that a significant part of the difficulties in the discussions
> about Taylor series and the like has been the lack of a common and
> unambiguous vocabulary. So, I've started a wiki page defining some
> concepts in order to clarify things:
> https://github.com/sympy/sympy/wiki/Function-expansions
> Feel free to expand or amend it, add links to and from it, etc.
> NB: I had to use Markdown syntax because I couldn't figure out how to
> get LaTeX to work in rST.
Thanks for writing this up, it will greatly help, and then we can
refactor it into sphinx later on (don't worry about using Markdown,
that's ok).
I agree with your definition of formal power series. Also with Laurent
+ Taylor series. So in other words, for analytic functions, Laurent
series is a Taylor series divided by some x^m (where m is an integer).
I agree with your O() definitions. Should we enable O() symbols around
different points than x=0 in sympy (including x=oo)? It now seems to
me we probably should.
How does asymptotic series fit into this? Series of the type 1 + 1/x +
1/x**2 + 1/x**3 and so on. Can it be viewed as Laurent series around
the point x=oo? This should be clarified and put there as well.
Ondrej
Alexey U. Gudchenko
> cos(x) as
> f(x) = 1 - 0.5 x2 + O(4).
> Note the O(4) term. I think this is usually done to reflect the fact that in
> this expansion cannot contain uneven powers of x as cos(x) is an even
> function
Formally, this variant do not reflect anything about even or odd terms
knowlage. It only reflect that some zeros terms intellectually
discovered: from 3 order (what precision was required) continually up to
some term (x^4) that founded as non zero.
Well, suppose this variant further with comparison of present.
First of all, can I be curious about another practical aims of this?
For example, present variant is can be used for this (for me):
"Give me terms only that is required for me, I do not want to know
unnecessary information and deal with it. Also, when I begin with some
asymptotic expansion with some precision, and then continue to work with
series (summation, multiplication and various operations) inform me the
finally (guaranteed) precision"
Your variant may be of course useful on some topics, but obviously it
produce some investigation about terms of series. So my conclusion is to
shape this variant logically separately. (f.e. as options of method, or
another method, or something else).
Alexey U. Gudchenko
Sorry, to avoid confusion I add some correction.
In previous message I was concentrated on the last terms and have think
about what to do with this f.e.:
>>> (cos(x) + x).series(x, n=3)
variant 1 (present):
1 + x - x**2/2 + O(x**3)
or
1 + x - x**2/2 + O(x**4)
The last variant produce some investigation about zero terms (from x^3)
and found non zero terms and signal about it with the help of O(x**4).
May be, I other word, it yield real precision of assymptotic expansion.
But if we revert to talk about even or odd terms, it is of course
additional investigation about terms.
Aaron S. Meurer
I agree. 1 + x + x**2/2 + O(x**3) is not a series. A series would be something like summation(x**n/factorial(n), (n, 0, oo)). We don't have anything like that implemented (though it would be awesome if we did).
On the other hand, "series" is a pretty standard name for that I think (Maple uses it for the same thing, for example).
I think the answer is just to be clear in the docstring.
Aaron Meurer
Alexander Eberspächer
On Wednesday, February 23, 2011 9:27:25 PM UTC+1, pr...@goodok.ru wrote:
and found non zero terms and signal about it with the help of O(x**4).
May be, I other word, it yield real precision of assymptotic expansion.
Alex
Alexander Eberspächer
On Wednesday, February 23, 2011 10:13:24 PM UTC+1, asmeurer wrote:
I agree. 1 + x + x**2/2 + O(x**3) is not a series. A series would be something like summation(x**n/factorial(n), (n, 0, oo)). We don't have anything like that implemented (though it would be awesome if we did).
The expansion 1 + x + x**2/2 + O(x**3) would be called "truncated Taylor series of order 2".
I think the answer is just to be clear in the docstring.
Greetings
Alex
Aaron S. Meurer
Hello,
On Wednesday, February 23, 2011 10:13:24 PM UTC+1, asmeurer wrote:I agree. 1 + x + x**2/2 + O(x**3) is not a series. A series would be something like summation(x**n/factorial(n), (n, 0, oo)). We don't have anything like that implemented (though it would be awesome if we did).
+1. Extremely useful. Also: +1 on Laurent series!
The expansion 1 + x + x**2/2 + O(x**3) would be called "truncated Taylor series of order 2".I think the answer is just to be clear in the docstring.
Yes. However, if in doubt, I think the standard maths terminology is to prefer over the terminology used in other computer algebra systems.
Greetings
Alex
Ondrej Certik
>
> On Feb 23, 2011, at 3:32 PM, Alexander Eberspächer wrote:
>
> Hello,
>
> On Wednesday, February 23, 2011 10:13:24 PM UTC+1, asmeurer wrote:
>>
>> I agree. 1 + x + x**2/2 + O(x**3) is not a series. A series would be
>> something like summation(x**n/factorial(n), (n, 0, oo)). We don't have
>> anything like that implemented (though it would be awesome if we did).
>
> +1. Extremely useful. Also: +1 on Laurent series!
I think that:
1 + x + x**2/2 + O(x**3)
is a series expansion. So I like the method name series().
>
> Do you know of any algorithms do to this? The only thing I can think of is
> to implement (for example with Taylor series) the most common cases (like
> exp(x), sin(x), etc.) and also the formulas for multiplying, adding, etc.
> series. But maybe there is some more general method that involves
> generating and solving some recurrence relations.
Algorithm for what? Laurent series? I think that is already implemented:
>>> e = sin(x)/x**4
>>> e.series(x, 0, 5)
1 1
- ─── + ── + O(x)
6⋅x 3
x
>>> e.series(x, 0, 10)
3 5
x 1 1 x x
─── - ─── + ── - ──── + ────── + O(x**6)
120 6⋅x 3 5040 362880
x
>>> e.series(x, 0, 15)
3 5 7 9
x 1 1 x x x x
─── - ─── + ── - ──── + ────── - ──────── + ────────── + O(x**11)
120 6⋅x 3 5040 362880 39916800 6227020800
x
>
> The expansion 1 + x + x**2/2 + O(x**3) would be called "truncated Taylor
> series of order 2".
>>
>> I think the answer is just to be clear in the docstring.
>
> Yes. However, if in doubt, I think the standard maths terminology is to
> prefer over the terminology used in other computer algebra systems.
>
> Another thing to consider is that the name "series" already exists in SymPy,
> and has for some time, so any changing would be a break in compatibility.
> But I agree that we should only use other CASs as guides, not as rules for
> what we should do.
I would stick to series(), as a general method for calculating the
most general series expansion around a point. I think that it can be
well defined. And possibly adding a kwarg "method", with values
"taylor", "laurent", "asymptotic", or anything else, to restrict it,
so that for example (sin(x)/x**4).series(method="taylor") returns an
exception, rather than the Laurent series above.
Ondrej
Alexey U. Gudchenko
> On Wed, Feb 23, 2011 at 3:12 PM, Aaron S. Meurer<asme...@gmail.com> wrote:
>>
>> On Feb 23, 2011, at 3:32 PM, Alexander Eberspächer wrote:
>>
>>
>> The expansion 1 + x + x**2/2 + O(x**3) would be called "truncated Taylor
>> series of order 2".
>>>
>>> I think the answer is just to be clear in the docstring.
>>
>> Yes. However, if in doubt, I think the standard maths terminology is to
>> prefer over the terminology used in other computer algebra systems.
>>
>> Another thing to consider is that the name "series" already exists in SymPy,
>> and has for some time, so any changing would be a break in compatibility.
>> But I agree that we should only use other CASs as guides, not as rules for
>> what we should do.
>
> I would stick to series(), as a general method for calculating the
> most general series expansion around a point. I think that it can be
>
> Ondrej
>
I supposed that name-token "series" was arised traditionally in the
historical way of CASs.
At first step there was a function that return series for the aim to
find it out, to learn it, to view of its terms (more exactly to view
coefficients of it), but it is obviously that computer machine can't
represent this terms infinitely on the screen, so it printed only some
terms and finished by "+ ..." f.e. ("1 + x + x^2/2 + ..."). So parameter
"n" was used for representation only.
Then it was improved, by adding the operations to work with the
truncated part (first n terms), in the beginning it was implemented as
operations by ordinary polynomials ("1 + x + x^2/2") (parameter "n" was
used for truncation to convert to polynomials). Then on the next step as
the series object (for performance aim also) , and on this step it was
required enhancement to track reminder part with the O(x) notation and
behavior. Also "..." was replaced by this one.
So at the end "series" turn into "asymptotic expansion". But at the same
time internal representation of Series (tracking of coefficients as
array) was saved too, and (I call attention) that "asymptotic expansion"
in this case not ordinary expression with O(x) but have internal
structure inherited from Series.
It is my estimates, I have not work with dinosaur CASs with series or do
not remember. but I see the rudiments and can explain them so as I written.
BTW, Sympy also begin this historical way, but the first step ("+ ...")
was omitted as I know.
> On Wednesday, February 23, 2011 10:13:24 PM UTC+1, asmeurer wrote:
>> I agree. 1 + x + x**2/2 + O(x**3) is not a series. A series would be something like summation(x**n/factorial(n), (n, 0, oo)). We don't have anything like that implemented (though it would be awesome if we did).
Generally, coefficients of the series can be represented not always by
formulas. So instead of "summation(a(n)* x**n/factorial(n), (n, 0, oo))"
(I have added "a(n)" to this example), the series object can be written
originally as "Series( exp(x), x0)" only (compare with Derivative).
And only if it is known that, Series can be represented as some
summation, then it can be shown (trough the some method logically).
More over, Series can be defined not from the function expansion, but
trough the manually definition of coefficients (by formula, or array in
the case of truncated "asymptotic expansion").
Then, I have seen that Ronan told about fields and ring structure of
series (infinity summations). So I having a right to ask is it planned
to consider Series (infinity case) with some operation with each other?
In the case of infinity summations, I do not realize how to use formulas
(aplyed upon coefficients f.e.) to do this because of infinity , and I
do not realize the usage of those operations exactly (may be only in the
case if formula of coefficients a(n) is known).
So my opinion do not create Serias class (infinity case), right now at
least.
Well, now I have come to conclusion that there are three kinds of
series/asymptotic expansion:
1) "Series" (infinity case)
This represent infinity summation, can be obtained from
function or manually defined by coefficients formula.
2) "asymptotic expansion" but with the saving of structure of Series.
It is truncated series. It can be obtained from function or
manually defined by coefficients formula or finite array, or it can be
obtaioned from "Series" expr.
And though it is really asymptotic expansion, but it maintain
series structure, for simplicity and perfomance of operations.
3) "asymptotic expansion" without maintaining structure of Series,
that is ordinary sympy expression with general O(x) term.
It can be obtained by the ways as writen before, but also can be
totaly defined as expr with the O term manually.
All three cases conected with each other in one way (forward only): the
last can be derived from the previous.
BTW, now in sympy the way is implemented so, that the 3) obtained
immediately with omitting previous steps (but they assumes).
> I would stick to series(), as a general method for calculating the
> most general series expansion around a point. I think that it can be
> well defined...
>
> Ondrej
>
In any case transformations with "series" name-token must be with careful.
All tests in many branches will be corrupted.
And also end user, who was accustomed to traditional meaning, can be
confused.
I propose to construct "asymptotic expansion", "Series" and so on in the
parallel mode (with other names token). Finally, (as variant) after
producing of them, then it can be applied as separate transaction to
reform traditional ".series" in a way just to use only the results of
"asymptotic expansion", "Series" and so on.
> And possibly adding a kwarg "method", with values
> "taylor", "laurent", "asymptotic", or anything else, to restrict it,
> so that for example (sin(x)/x**4).series(method="taylor") returns an
> exception, rather than the Laurent series above.
>
> Ondrej
>
I again chose the point of view as the end-user aims.
When I ask sympy for "series()" I mean "I do not know about various
names of series, please give me something, show me what you can do
intellectually". So "series()" do additional distribution job.
The result of this method yield specific series (I vote that it must be
separated classes "SeriesTeylor" and so on, so first of all I can see
what kind of series is returned, also implementation and behavior of
them are various).
Of course, some expresion can be written as variouse types of series
(Furrier or Taylor). Or I want to so specify more exactly what I need.
So I agree that it can be kwarg "method" and exception if it can't exists.
And I have some little question about Laurent.
exp(1/x).series(x, oo) = 1 + 1/x + 1/(2*x**2) ...
Is it Laurent or power series?
Alexander Eberspächer
On Thu, 24 Feb 2011 09:58:59 +0300
"Alexey U. Gudchenko" <pr...@goodok.ru> wrote:
> And I have some little question about Laurent.
>
> exp(1/x).series(x, oo) = 1 + 1/x + 1/(2*x**2) ...
>
> Is it Laurent or power series?
In my use of maths language, this is a Laurent series as negative
powers of x contribute. Power series (or, in this case, Taylor series)
contain only exponents in [0; oo). So I would call this expansion a
Laurent series about the point x=oo.
Quickly browsing through the Mathematica 8 documentation, it seems that
Mathematica does not offer more much functionality than SymPy does (or
will do with that Series branch). The documentation also is fuzzy about
terminology. It describes that Series[] gives a series that may be a
(truncated ) Taylor series or another, more general type of series with
generalized powers (such as fractional powers). I haven't found a
command to explicitly generate Laurent series.
Cheers
Alex
Alexey U. Gudchenko
> Hello,
>
> On Thu, 24 Feb 2011 09:58:59 +0300
> "Alexey U. Gudchenko"<pr...@goodok.ru> wrote:
>
>> And I have some little question about Laurent.
>>
>> exp(1/x).series(x, oo) = 1 + 1/x + 1/(2*x**2) ...
>>
>> Is it Laurent or power series?
>
> In my use of maths language, this is a Laurent series as negative
> powers of x contribute. Power series (or, in this case, Taylor series)
> contain only exponents in [0; oo). So I would call this expansion a
> Laurent series about the point x=oo.
I think so.
In [1] there is defined only "formal Laurent series" in which only
finite number of negative powers is allowed.
But generally "Laurent series" can contain infinitely number of terms
with negative powers. So it must be reflected in [1], and distinguished.
If there are no objections.
In this case (opposite to "formal Laurent series") there are not general
rules how to multiplicate series with each other.
By the way in [1]:
"K[[X]] and has a ring structure."
"K((X)) and has a field structure."
I do not understand the difference about ring structure or field
structure. (Is it misprint?)
Also, as number of terms with positive powers in "Laurent series" can be
infinitely too with the same time as negative ones, it's interesting in
this case what to do with O() when consider some asymptotic expansion
from this series or does sense of it exists, and what sort of if it
does. I do not know exactly the answer now.
Alexey U. Gudchenko
Well, so can you offer what interface (f.e. options of method,
name-token for it) is more convenient and clear for end user for this
enhancement?
I think it can be posted directly to the sympy issues tracker [1] if
there are no doubts.
Alexander Eberspächer
On Thu, 24 Feb 2011 15:52:07 +0300
"Alexey U. Gudchenko" <pr...@goodok.ru> wrote:
> But generally "Laurent series" can contain infinitely number of terms
> with negative powers. So it must be reflected in [1], and
> distinguished. If there are no objections.
I think so, too.
> In this case (opposite to "formal Laurent series") there are not
> general rules how to multiplicate series with each other.
Yes. To my (limited) understanding, in this case one cannot speak of a
field or ring structure, as both require a multiplication.
> By the way in [1]:
> "K[[X]] and has a ring structure."
> "K((X)) and has a field structure."
>
> I do not understand the difference about ring structure or field
> structure. (Is it misprint?)
IIRC, a ring is basically a field minus the division and subtraction
operation. However, algebraic structures are certainly "none of my
business".
I want to add one more keyword to the discussion: Google just taught me
about Puiseux series (http://en.wikipedia.org/wiki/Puiseux_series),
which seem to be series with rational exponents on the base functions.
> Also, as number of terms with positive powers in "Laurent series" can
> be infinitely too with the same time as negative ones, it's
> interesting in this case what to do with O() when consider some
> asymptotic expansion from this series or does sense of it exists, and
> what sort of if it does. I do not know exactly the answer now.
Me neither. If this is unclear it is possibly the best options not to
provide the order of the remainder terms.
Alex
Alexey U. Gudchenko
Thank you for reminding about algebraic structures...
> I want to add one more keyword to the discussion: Google just taught me
> about Puiseux series (http://en.wikipedia.org/wiki/Puiseux_series),
> which seem to be series with rational exponents on the base functions.
I think that in Ronan's wiki page must be a sections with description of
various kinds of Series.
(I am sorry, but it is hard to me in this week to edit this page with LaTeX)
>> Also, as number of terms with positive powers in "Laurent series" can
>> be infinitely too with the same time as negative ones, it's
>> interesting in this case what to do with O() when consider some
>> asymptotic expansion from this series or does sense of it exists, and
>> what sort of if it does. I do not know exactly the answer now.
>
>
> Alex
>
I have seen just now (I can't read and translate all messages quickly
now) that Ondrej yesterday have bring up almost similar question what to
do with the series like "1 + 1/x + 1/x**2 and so on".
> Me neither. If this is unclear it is possibly the best options not to
> provide the order of the remainder terms.
I should to bring you up to date about providing. At the last week or
two it was discussed about it, if we saying about "asymptotic expansion"
(by implication) then O() must be present. Ronan protested against
omitting O() in this case, there is one reason among others why he was
inspired to write wiki page we talk about in this thread.
So we distinguish now the Series and "asymptotic expansion".
And (as I understand Ronan's tendency) if we can't provide O(x) then we
can't provide "asymptotic expansion" upon the whole. (only some terms,
that generally speaking is neither "asymptotic expansion", nor Series,
just truncated terms of Series).
In other world the task of obtaining "asymptotic expansion" is
considered to be solved only if appropriate O(x) is provided.
And if we provide only truncated terms then it is truncated Series only,
nothing else.
Aaron S. Meurer
I think Mathematica can do more than SymPy, because for example, if you type "series of sin(x)" into Wolfram|Alpha (http://www.wolframalpha.com/input/?i=series%20of%20sin(x)), you get both x-x^3/6+x^5/120-x^7/5040+x^9/362880+O(x^10) and sin(x) = sum_(k=0)^infinity((-1)^k x^(1+2 k))/((1+2 k)!).
Aaron Meurer
Alexey U. Gudchenko
> Hi Ronan!
>
> On Tue, Feb 22, 2011 at 7:12 PM, Ronan Lamy<ronan...@gmail.com> wrote:
>> I think that a significant part of the difficulties in the discussions
>> about Taylor series and the like has been the lack of a common and
>> unambiguous vocabulary. So, I've started a wiki page defining some
>> concepts in order to clarify things:
>> https://github.com/sympy/sympy/wiki/Function-expansions
>> Feel free to expand or amend it, add links to and from it, etc.
>> NB: I had to use Markdown syntax because I couldn't figure out how to
>> get LaTeX to work in rST.
>
> Thanks for writing this up, it will greatly help, and then we can
> refactor it into sphinx later on (don't worry about using Markdown,
> that's ok).
>
> I agree with your definition of formal power series. Also with Laurent
> + Taylor series. So in other words, for analytic functions, Laurent
> series is a Taylor series divided by some x^m (where m is an integer).
And today's remarks about difference between "Laurent series" and
"formal Laurent series" must be taken into consideration.
> I agree with your O() definitions. Should we enable O() symbols around
> different points than x=0 in sympy (including x=oo)? It now seems to
> me we probably should.
Of course we should, (it hang smichr/2084).
As it begin track point x0, so it is assumed that the whole expression
tend to x0 too.
So O((x-x0)**n) must be determ terms (x-x0)**k of it expression to deal
with them. Don't it?
Also operations with the expressions that contains O((x-x0)**n) (so it
tend to x0) on the one hand and O((x-x1)**n) that tend to x1 on the
other hand must be not allowed.
Then, I supposed that various particular class of O can be implemented
(almost accordingly various kinds of series) that derived from O, which
can be defined generally, as Ronan written.
Chris Smith
> we can't provide "asymptotic expansion" upon the whole. (only some terms,
> that generally speaking is neither "asymptotic expansion", nor
An order term is always returned now.
Until we can represent O at x0!=0 the origin is simply shifted to x0 as it says in the docstring.
If you want the "unshifted, but not fully functional" form you can use the keyword sudo=True:
h[1] >>> cos(x).series(n=2)
1 + O(x**2)
h[2] >>> cos(x).series(x,1,n=2)
-x*sin(1) + cos(1) + O(x**2)
h[3] >>> cos(x).series(x,1,n=2,sudo=True)
(1 - x)*sin(1) + cos(1) + O((x - 1)**2)
/c
Ondrej Certik
I think that the above is ok with me for now. I would push your branch
in and improve upon it. Let's wait if there are any more objections,
and if not, let's do it.
Ondrej
Alexey U. Gudchenko
I think, "sudo" must be True by default for end-user (or/and therefore
with other name-token):
> h[2]>>> cos(x).series(x,1,n=2)
> (1 - x)*sin(1) + cos(1) + O((x - 1)**2)
It is almost ideal result.
(only without canonical representation: terms sorting and (1-x) instead
of (x-1)).
Conversely, internal calling if series in therefore must be with (...,
somthing_hack=True) if it options is needed.
> h[3]>>> cos(x).series(x,1,n=2, somthing_hack=True)
> -x*sin(1) + cos(1) + O(x**2)
This result is incorrect and I don't understand the usage of it, except
the internal core or temporary usage.
Proposed variant having more sense and also remind us the reasons for
this options usage in core.
But if it is hard to correct all branches, and because of the
temporarily usage of this option in core (until O((x - 1)**2) will be
enabled as I understand), it is not principally right now. But in future
it will be.
Alexey.
Alexey U. Gudchenko
Excuse me pure Englsih,
> Conversely, internal calling if series in therefore must be with (...,
> somthing_hack=True) if it options is needed.
Must be read as:
Conversely, internal calling of series method therefore must be with
option (..., somthing_hack=True) if it options is needed.
Alexey U.
Chris Smith
> 25.02.2011 08:59, Alexey U. Gudchenko пишет:
>
> option (..., somthing_hack=True) if it options is needed.
>
If you mean that something internal wants the unshifted series, then yes sudo=True should be used and the O term removed. This would be the same thing as getting the shifted series, removing the O term and doing the substitution yourself of `s.removeO().subs(x, x-x0)`.
So if there are no objections, I'll commit this in about 5 hours.
/c
Alexey U. Gudchenko
Sorry, no.
I try to rewrite (more for me) again more exactly.
My soft objection was to define option "sudo" as default to be True.
End-user have not to know about internal methods (shifting or not) for
obtaining correct result on a whole, and about "sudo" option in particular.
In your example
> h[2] >>> cos(x).series(x,1,n=2)
> -x*sin(1) + cos(1) + O(x**2)
> h[3] >>> cos(x).series(x,1,n=2,sudo=True)
> (1 - x)*sin(1) + cos(1) + O((x - 1)**2)
result h[2] is incorrect and out of sense for end-user, but result h[3]
is valid.
I do not understand why you call valid result h[3] as special "unshifted
series" and was concentrated to this (special case is rather "shifted"
h[2], and only incorerct h[2] can be used for internal usage, I have do
mean it)
So I offer change:
>>> def series(self, x=None, x0=0, n=6, dir="+", sudo=False):
>>> ...
to
>>> def series(self, x=None, x0=0, n=6, dir="+", sudo=True):
>>> ...
at least formally.
This bring to:
> h[2] >>> cos(x).series(x,1,n=2)
> (1 - x)*sin(1) + cos(1) + O((x - 1)**2)
> h[3] >>> cos(x).series(x,1,n=2,sudo=False)
> -x*sin(1) + cos(1) + O(x**2)
so h[2] became correct now.
(more deeper also change name-token because it become something confused
meaning)
But:
It may be impossible (I think because of the architecture) or hard
(because of all calling of series() in core must be reformed).
So my objection was a kind of wanning rather.
Nevertheless, In any case, this all written is not principally because
of temporarily usage of this option in core (I hope until O((x - 1)**2)
will be enabled) and it is not worth the trouble.
Alexey U.
Ronan Lamy
Wait. I don't think that adding yet another option is a good idea,
particularly when its purpose is to choose between two bad workarounds.
And 'sudo' is a bad name anyway.
Chris Smith
> Le vendredi 25 février 2011 à 16:26 +0545, Chris Smith a écrit :
>> Alexey U. Gudchenko wrote:
>>> 25.02.2011 08:59, Alexey U. Gudchenko пишет:
>>>
>>> Conversely, internal calling of series method therefore must be with
>>>
>>
>> If you mean that something internal wants the unshifted series, then
>> yes sudo=True should be used and the O term removed. This would be
>> the same thing as getting the shifted series, removing the O term and
>> doing the substitution yourself of `s.removeO().subs(x, x-x0)`.
>>
>> So if there are no objections, I'll commit this in about 5 hours.
>
> Wait. I don't think that adding yet another option is a good idea,
> particularly when its purpose is to choose between two bad
> workarounds. And 'sudo' is a bad name anyway.
Aaron and I were discussing keywords that basically mean "let me do this, I know what I'm doing" and he (I think lightheartedly) pointed out that in unix, "sudo" is used for such operations: "super user do" = "do what I'm telling you, I accept all consequences; I know what I'm doing." It's non-sympy enough to draw attention to itself as something to not be used without reading what it means. If you have an alternative, please put it forward for discussion.
As to adding another option....what's the alternative? We don't want a series without an O() (that would suggest that it is exact) and we can't represent it accurately with the machinery of the existing O(). So until we do, these commits have fixed a lot, raised issues for future work, and hopefully haven't broken anything. What harm is there in fixing the existing status even if it doesn't bring that status up to where we want it to be?
/c
Alexey U. Gudchenko
Excuse me,
> choose between two bad workarounds.
Why f.e. this variant:
> h[2]>>> cos(x).series(x,1,n=2)
> (1 - x)*sin(1) + cos(1) + O((x - 1)**2)
is bad ?
(except canonical representation of series, and your remarks that it is
"asymptotic expansion" indeed, not series)
I.
If there are problems with O((x - 1)**2) and its behavior then problem
is there in O((x - 1)**2) itself.
Generaly, I can obtain so called "asymptotic expansion" manually without
usage of series.
>>> 1 + x + O(x**2)
1 + x + O(x**2)
and I can use operation with this
>>> ae = 1 + x + O(x**2)
>>> (ae * ae).expand()
1 + 2*x + O(x**2)
This way I can operate with "asymptotic expansion" expression manually
(without any knowlage of series).
And it is needed to support x0 in O(x) too. Though, now even constructor
of Order do not permit to specify x0 point, but suppose that it does,
first of all simply as object property, even without right
representation or behavior.
First step.
Then Chris can have all the rights to use this constructor of O for
final result of series
Second step.
And other problems (which are concerned with operations with "asymptotic
expansion" expression resulted by "series()", or concerned with
operations with O() and even concerned with representations of O()) -
they will be encapsulated in O, because they will be raised with
manually usage "asymptotic expansion" itself too.
Third step - solve problems with O() and "asymptotic expansion" at the
point x0.
I do not consider now the cases with 1/oo or rational powers, but they
will be separated by the same way, with remarks that various kind of
classes may be defined probably.
And I warn, about third step that the problems with O itself and with
operations by "asymptotic expansion" expression in manually mode will be
hard, (without of series structure knowledge). On the other hand
problems with "series()" Chris's work will be logically and tactical
separated.
II.
if you mean that ".series()" it is "asymptotic expansion" indeed, not
series, then it is another question.
I wrote earlier some remarks, offers and its arguments, that work with
"asymptotic expansion" can be executed in parallel mode.
Alexey U.
Ronan Lamy
> 25.02.2011 16:03, Ronan Lamy пишет:
> > Le vendredi 25 février 2011 à 16:26 +0545, Chris Smith a écrit :
> >> Alexey U. Gudchenko wrote:
> >>> 25.02.2011 08:59, Alexey U. Gudchenko пишет:
> >>>
> >>> Conversely, internal calling of series method therefore must be with
> >>> option (..., somthing_hack=True) if it options is needed.
> >>>
> >>
> >> If you mean that something internal wants the unshifted series, then
> >> yes sudo=True should be used and the O term removed. This would be the
> >> same thing as getting the shifted series, removing the O term and
> >> doing the substitution yourself of `s.removeO().subs(x, x-x0)`.
> >>
> >> So if there are no objections, I'll commit this in about 5 hours.
> >
> > Wait. I don't think that adding yet another option is a good idea,
> > particularly when its purpose is to choose between two bad workarounds.
> > And 'sudo' is a bad name anyway.
> >
>
> Excuse me,
>
> > choose between two bad workarounds.
>
> Why f.e. this variant:
>
> > h[2]>>> cos(x).series(x,1,n=2)
> > (1 - x)*sin(1) + cos(1) + O((x - 1)**2)
>
> is bad ?
What's bad is that '(x - 1)' in the O() is actually a symbol that's
completely unrelated to x. This could be very confusing and it's
unlikely that such an expression will be handled correctly by existing
functions.
> (except canonical representation of series, and your remarks that it is
> "asymptotic expansion" indeed, not series)
As you said, these problems are unrelated with Chris's work.
>
>
> I.
> <snip>
I agree that O() needs to be fixed to take an x0 argument before we can
represent expansions at a point other than 0. Correct handling of all
cases (x0 = oo, O(1, x, x0=0) + O(1, x, x0=1), ...) can probably wait.
Chris Smith
>> Why f.e. this variant:
>>
>> > h[2]>>> cos(x).series(x,1,n=2)
>> > (1 - x)*sin(1) + cos(1) + O((x - 1)**2)
>>
>> is bad ?
>
> What's bad is that '(x - 1)' in the O() is actually a symbol that's
> completely unrelated to x. This could be very confusing and it's
> unlikely that such an expression will be handled correctly by existing
> functions.
What's good is that only the user that reads the docstring is going
to be able to figure out how to do this. Anyone else is going to just
get the shifted function result. The commit message is also clear
about what's happening:
2) if sudo=True then return the expression with a non-functional
but proper looking O() term. Symbol trickery is used here to
replace x with Symbol(str(x-x0)) in the O() term.
> I agree that O() needs to be fixed to take an x0 argument before we
> can represent expansions at a point other than 0. Correct handling of all
> cases (x0 = oo, O(1, x, x0=0) + O(1, x, x0=1), ...) can probably wait.
Are you ok with proceeding, then? If not, could you clearly tell what it would
take to get a positive vote?
/c
Chris Smith
>When in shark infested waters, first stop the bleeding, then swim carefully to safer waters.
There are many bleeding issues that have been fixed with this work. We are still in shark infested waters but that's the next issue. Can you summarize your sentiments against making these changes?
Ronan Lamy
> Ronan Lamy wrote:
> >> Why f.e. this variant:
> >>
> >> > h[2]>>> cos(x).series(x,1,n=2)
> >> > (1 - x)*sin(1) + cos(1) + O((x - 1)**2)
> >>
> >> is bad ?
> >
> > What's bad is that '(x - 1)' in the O() is actually a symbol that's
> > completely unrelated to x. This could be very confusing and it's
> > unlikely that such an expression will be handled correctly by existing
> > functions.
>
> What's good is that only the user that reads the docstring is going
> to be able to figure out how to do this. Anyone else is going to just
> get the shifted function result. The commit message is also clear
> about what's happening:
>
> 2) if sudo=True then return the expression with a non-functional
> but proper looking O() term. Symbol trickery is used here to
> replace x with Symbol(str(x-x0)) in the O() term.
I don't see the point of this, actually. The expression is only good for
printing, but users who know what they're doing can easily get a "nice"
expression with, for instance, expr.series(x, 1, n=2).subs(x,
Symbol(str(x-1))). On the other hand, every new option doubles the
amount of testing we should do and increases the cognitive burden on the
user.
> > I agree that O() needs to be fixed to take an x0 argument before we
> > can represent expansions at a point other than 0. Correct handling of all
> > cases (x0 = oo, O(1, x, x0=0) + O(1, x, x0=1), ...) can probably wait.
>
> Are you ok with proceeding, then? If not, could you clearly tell what it would
> take to get a positive vote?
Remove the 'sudo' option.
Everything else looks good to me - though I'm sure that given enough
time, I could still find a few reason to nitpick.
Chris Smith
> Remove the 'sudo' option.
> Everything else looks good to me - though I'm sure that given enough
> time, I could still find a few reason to nitpick.
OK, thanks. I will make that change. Could you (or anyone else) please focus your nitpick skills on the "use standard O term" commit? I think when you commented on it before you were focussed on the terms of the series, but I don't know if always using `O(x**n)` is the right thing to do. (And I know that sometimes we might want to return `O(x**7)` instead of `O(x**6)` if there are no `x**6` terms, but that is another issue.)
/c
Alexey U. Gudchenko
A. My fears that it will be hard to maintain behavior of O((x-x0)**n)
for pure "asymptotic expansions" expression in general case (without
knowledge of series structure). In this case O((x-x0)**n) must detect
and catch (x-x0)**k terms in a whole expression for every operation. And
detect and do not permit operations between expressions which contain
O((x-x1)**n) and O((x-x2)**n) respectively (x1 <> x2).
B. I realize only maintaining of O behavior "asymptotic expansions" with
knowing series structure ( 2) in [1] )
Nevertheless, I observe consensus that A *or* B must be implemented
obligatory.
And what is more, both A *and* B implementations better.
[1] http://groups.google.com/group/sympy/msg/6d07d49dfde6ac5c?hl=en
Alexey U.
Vinzent Steinberg
should be marked as such). I think it is still better than no O() term
at all.
> B. I realize only maintaining of O behavior "asymptotic expansions" with
> knowing series structure ( 2) in [1] )
>
> Nevertheless, I observe consensus that A *or* B must be implemented
> obligatory.
> And what is more, both A *and* B implementations better.
Vinzent
Alexey U. Gudchenko
> I think that a significant part of the difficulties in the discussions
> about Taylor series and the like has been the lack of a common and
> unambiguous vocabulary. So, I've started a wiki page defining some
> concepts in order to clarify things:
> https://github.com/sympy/sympy/wiki/Function-expansions
> Feel free to expand or amend it, add links to and from it, etc.
> NB: I had to use Markdown syntax because I couldn't figure out how to
> get LaTeX to work in rST.
>
> Expr.series:
> * The order is off by one.
> * Its name is misleading since it doesn't return a series.
>
I am going to insert some little updates to this page.
But after thinkings, my opinion shaped that the title must be extended
On the one hand the series and expansion have self-dependent meanings
but they are intersected with each other on the other hand, that is why
they can be considered altogether. So for the present I create separated
page [2] temporary.
Changes:
- added classical **Laurent series**
- separated Series and expansions sections.
- for **Taylor series** added X = x - x0
- "generating function" sections added
- At Current situation "Sum" (summation) class mentioned.
If you have not objections I will insert changes to original [1] (for
changes history tracking) then (if I will be able to) rename it to the
"Series and function expansions" title.
[1] https://github.com/sympy/sympy/wiki/Function-expansions
[2] https://github.com/sympy/sympy/wiki/Function-expansions-and-series
Then I plan to add a few lines about mathematical reasons for series and
asymptotic expansions, and about purpose-oriented mathematical operation
with them. After that I will be able to formulate what I want from sympy
technically.
Alexey U.
Alexey U. Gudchenko
>> A. My fears that it will be hard to maintain behavior of O((x-x0)**n)
>> > for pure "asymptotic expansions" expression in general case (without
>> > knowledge of series structure). In this case O((x-x0)**n) must detect
>> > and catch (x-x0)**k terms in a whole expression for every operation. And
>> > detect and do not permit operations between expressions which contain
>> > O((x-x1)**n) and O((x-x2)**n) respectively (x1<> x2).
> It would be a "for-the-moment" fix which is likely to be changed (and
> should be marked as such). I think it is still better than no O() term
> at all.
>
>> > B. I realize only maintaining of O behavior "asymptotic expansions" with
>> > knowing series structure ( 2) in [1] )
>> >
>> > obligatory.
>> > And what is more, both A*and* B implementations better.
> Could you please explain what you mean with the last sentence?
>
> Vinzent
>
Well, It will be easer to explain from the point of view of programmer.
It is clear that "A" is sympy Add class which consists of polynomials
terms "a_n (x-x0)**n" and O((x-x0)**n).
In "B" is imagined class TaylorExpansion that implement the "n-th order
Taylor expansion" so it track his precision (n), the list of [a_n],
variable x, and point x0.
[a_n] may by any sympy expression, not necessarily numbers.
It has self-depended method for representation it in sympy (print) to
print "a0 + a1*(x - x0) + ... + O(x - x0)"
It has method "asExpr()" to shape "A" variant for general propose.
It has method "truncate" to form Taylor polynomial. May be another class
too if it has not analog in polynomials module yet.
The reason of this class - that manipulations with its objects will be
easer.
F.e. the derivative of it will bring to the same object but the list of
[a_n] will be shifted throu its index by one and precision will be
decremented.
Summation equivalent to summation of lists (c_i = a_i + b_i), with
alignment of precision to minimal value of both.
Multiplication will be a little complex, but still without analyzing
(x-x0)**k parts of expression.
May be I became entangled now it with similar "exponential generating
function", but the last one is not derived from function (opposite to
Taylor), and it is not expansion (it is series).
--
Alexey U.
Aaron S. Meurer
It sounds like a special TaylorExpansion class should be implemented as a wrapper around Poly.
Aaron Meurer
Alexey U. Gudchenko
It is not now clear for me what the class's hierarchy must be right now,
Its preliminary rough ideas, based in particular what I have seen in
Wolfram Mathematica or in thread in sympy-maillist, or upon common sense.
Right now I learn closely the documentation of Wolfram Mathimatica for
further construction of the sympy wiki page about series and function
expansion, many things are good and I hope will be in sympy in future,
some nitpicks are present too.
Return to Poly...
Polynomials as I know concentrated on the tasks that is special for
them: finding roots, factorization, orthogonal and so on... Not only for
effective binary operations with them. Many of them (generally saying)
are out of sense for asymptotic expansions (when expression consist of O()).
Also, If someone wants to use the code of Polys then it is better to
obtain "Taylor polynomial" throu some method (I have mentioned it in
previously message). It wold be clear both for user and sympy what
context he is mean.
Also, I don't know exactly right now, whether TaylorExpansion or
TaylorSerias must be know something about source function (from which
this object is derived) for some future tasks connected with convergence
and so on. And finite Polys don't know anything about convergence.
So I have doubts for TaylorExpansion to be inherited from Polys.
Nevertheless all this is roughly now.
After formulation from every quarter what we must expect mathematically
and from sympy (I work with this though not quickly), only then we can
be able saying about concrete implementation.
--
Alexey U.
Aaron Meurer
Just to be clear, I don't necessarily think that it should subclass
from Poly. I just think that the series structure should internally
use a Poly, because otherwise we will end up reimplementing the basic
arithmetics, like multiplication, etc. Also, Poly is very fast (much
faster than an Expr object). Of course, the object should also
contain other information, like the original function and the O()
term, so it may make more sense to make the Poly just an attribute of
the object. rather than making the object derive from Poly (I really
don't know which would be better; you can think about that).
Aaron Meurer
Alexey U. Gudchenko
> 23.02.2011 06:12, Ronan Lamy пишет:
Added:
In [2] added:
* remarks what is *formal* means
* In "current situation" section added:
- "But the present method "series" which returns various kinds of
series is convenient and used for the task of *limits* processing..."
- mention that "Also the implementation of some series methods for
solving IDEs is processing now in Saptarshi's branch"
- "problems and remarks which we encounter" subsection
* "Usage and application" section
[2] https://github.com/sympy/sympy/wiki/Function-expansions-and-series
Alexey U.
Alexey U. Gudchenko
>> 23.02.2011 06:12, Ronan Lamy пишет:
>>> I think that a significant part of the difficulties in the discussions
>>> about Taylor series and the like has been the lack of a common and
>>> unambiguous vocabulary. So, I've started a wiki page defining some
>>> concepts in order to clarify things:
>>> https://github.com/sympy/sympy/wiki/Function-expansions
>>> Feel free to expand or amend it, add links to and from it, etc.
>>> NB: I had to use Markdown syntax because I couldn't figure out how to
>>> get LaTeX to work in rST.
>>>
>>> Also while writing it, I've noticed 2 additional problems with
>>> Expr.series:
>>> * The order is off by one.
>>> * Its name is misleading since it doesn't return a series.
>>>
>>
>>
Hi,
I have updated [1] page with mathematical definitions.
Also I begin page in which we are concentrating to the end-user's aims
of series usage [2].
Other variants of usage are welcome, and questions too.
Many complexes cases are omitted, but we must correct main stream of
this document.
I hope after this we will be possible to turn into production of the
concrete plan of the implementations.
And if you have no objections I will remove original [3].
[1] https://github.com/sympy/sympy/wiki/Function-expansions-and-series
[2] https://github.com/sympy/sympy/wiki/Function-expansions-and-series-2
[3] https://github.com/sympy/sympy/wiki/Function-expansions
--
Alexey U.