@jschulzb Note that DEplot and DEplot3d can do animations too.

That may well be an effective and reasonably efficient way to show evolution in time from a/some initial conditions (ICs).

If, on the other hand, you intend on animating with respect to some other parameter that appears in an IVP's DEs or in its ICs and if you need it quicker than DEplot offers then you might take a glance at this.

@maple fan I'm afraid that a bug in the memory management of high precision LinearAlgebra causes the calculation to use up prohibitively too much memory in Maple 13. It is fixed in Maple 16, which is what I used above.

You can do the calculation quickly at hardware double precision at Digits=15, even in Maple 13, though, and see the relationship between accuracy and the reported condition numbers. Basically, there is an approximate near linear relationship between Digits and the error of a computed eigenvalue and the log[10] of its condition number.

For your example, the worst condition numbers are about 1e-13 and so when the calculation is done using fast hardware double precision (about Digits=15 in base 10) then there are only a couple of accurate decimal digits in those most troublesome of the computed eigenvalues. The best eigenvalues have condition number of about 1e-2 and the double precision results are likely accurate to about 12-13 decimal digits, etc (I haven't measured them precisely for your example, but it should be near that ballpark). So to get even the worst conditioned eigenvalues accurate to over 10 decimal digits the computation can be done with a working precision of Digits around 25-30 or so. I used Digits=35 above and seemed to get all roots accurate to 15 decimal places.

Unfortunately Digits=15 is as high as you can go before needing "software, high precision", where the mentioned bug exists before Maple 16. (Actually, I recall that the bug may have only appeared about Maple version 10 or 11.)

If you need it quick then in Maple 13, you can probably compute all the roots to about 10 correct places by using EigenConditionNumbers at Digits=15 and then using something like RootFinding:-Analytic on suitably restricted complex ranges to get the badly conditioned eigenvalues/roots (ie. those for which the condition number is worse that about 1e-4 or 1e-5).

In my experience all this is often not necessary, and fsolve can compute all roots of even badly conditioned univariate polynomials. I consider you example out of the ordinary, hitting some bug in the internal routine `fsolve/polyill` where it may be getting into a nonterminating loop or something.

If the condition numbers are all at least better than, say, 1e-14 then you may get about 1 correct digit in even the worst eigenvalue in the results from executing EigenConditionNumbers at Digits=15 and fast hardware double precision. If that is true then even if not fully accurate those eigenvalue estimates may be close to giving you a workable estimate of the spectral radius. Maybe.

@maple fan I'm afraid that a bug in the memory management of high precision LinearAlgebra causes the calculation to use up prohibitively too much memory in Maple 13. It is fixed in Maple 16, which is what I used above.

You can do the calculation quickly at hardware double precision at Digits=15, even in Maple 13, though, and see the relationship between accuracy and the reported condition numbers. Basically, there is an approximate near linear relationship between Digits and the error of a computed eigenvalue and the log[10] of its condition number.

For your example, the worst condition numbers are about 1e-13 and so when the calculation is done using fast hardware double precision (about Digits=15 in base 10) then there are only a couple of accurate decimal digits in those most troublesome of the computed eigenvalues. The best eigenvalues have condition number of about 1e-2 and the double precision results are likely accurate to about 12-13 decimal digits, etc (I haven't measured them precisely for your example, but it should be near that ballpark). So to get even the worst conditioned eigenvalues accurate to over 10 decimal digits the computation can be done with a working precision of Digits around 25-30 or so. I used Digits=35 above and seemed to get all roots accurate to 15 decimal places.

Unfortunately Digits=15 is as high as you can go before needing "software, high precision", where the mentioned bug exists before Maple 16. (Actually, I recall that the bug may have only appeared about Maple version 10 or 11.)

If you need it quick then in Maple 13, you can probably compute all the roots to about 10 correct places by using EigenConditionNumbers at Digits=15 and then using something like RootFinding:-Analytic on suitably restricted complex ranges to get the badly conditioned eigenvalues/roots (ie. those for which the condition number is worse that about 1e-4 or 1e-5).

In my experience all this is often not necessary, and fsolve can compute all roots of even badly conditioned univariate polynomials. I consider you example out of the ordinary, hitting some bug in the internal routine `fsolve/polyill` where it may be getting into a nonterminating loop or something.

If the condition numbers are all at least better than, say, 1e-14 then you may get about 1 correct digit in even the worst eigenvalue in the results from executing EigenConditionNumbers at Digits=15 and fast hardware double precision. If that is true then even if not fully accurate those eigenvalue estimates may be close to giving you a workable estimate of the spectral radius. Maybe.

@Cody With a few edits and corrections, your PSeries can do both, sure.

> PSeries:=proc(cfn,var,minreg::integer,maxreg::integer)
>   local r,imaxreg,iminreg;
>     if minreg>maxreg then
>       imaxreg:=minreg; iminreg:=maxreg;
>     else
>       imaxreg:=maxreg; iminreg:=minreg;
>     end if;
>      add(cfn(r)*var(r),r=iminreg..imaxreg);
>   end proc:
 
> PSeries(i->1/i!, R->x^R, 2, 0);

                                             2
                                1 + x + 1/2 x

 
> PSeries(i->(-1)^(i-1), R->1/R^2, 4, 1);

                                      115
                                      ---
                                      144

 
> h:=proc(n::posint)
>   local i;
>   add( (-1)^(i-1) * 1/i^2 , i=1..n );
> end proc:
 
> seq(h(i),i=1..6);

                                  31  115  3019  973
                          1, 3/4, --, ---, ----, ----
                                  36  144  3600  1200

> seq( PSeries(i->(-1)^(i-1), R->1/R^2, i, 1), i=1..6);

                                  31  115  3019  973
                          1, 3/4, --, ---, ----, ----
                                  36  144  3600  1200

@Cody With a few edits and corrections, your PSeries can do both, sure.

> PSeries:=proc(cfn,var,minreg::integer,maxreg::integer)
>   local r,imaxreg,iminreg;
>     if minreg>maxreg then
>       imaxreg:=minreg; iminreg:=maxreg;
>     else
>       imaxreg:=maxreg; iminreg:=minreg;
>     end if;
>      add(cfn(r)*var(r),r=iminreg..imaxreg);
>   end proc:
 
> PSeries(i->1/i!, R->x^R, 2, 0);

                                             2
                                1 + x + 1/2 x

 
> PSeries(i->(-1)^(i-1), R->1/R^2, 4, 1);

                                      115
                                      ---
                                      144

 
> h:=proc(n::posint)
>   local i;
>   add( (-1)^(i-1) * 1/i^2 , i=1..n );
> end proc:
 
> seq(h(i),i=1..6);

                                  31  115  3019  973
                          1, 3/4, --, ---, ----, ----
                                  36  144  3600  1200

> seq( PSeries(i->(-1)^(i-1), R->1/R^2, i, 1), i=1..6);

                                  31  115  3019  973
                          1, 3/4, --, ---, ----, ----
                                  36  144  3600  1200

@mzh I just wrote Shift-minus because that's where the underscore is on my keyboard.

I believe that Command-underscore should get the subliteral on OSX. See the 2D Math shortcut keys help-page.

@mzh I just wrote Shift-minus because that's where the underscore is on my keyboard.

I believe that Command-underscore should get the subliteral on OSX. See the 2D Math shortcut keys help-page.

@jscottelder I didn't use any command from the IntegrationTools package here.

@jscottelder I didn't use any command from the IntegrationTools package here.

I am guessing that he is using 2D Math input and has a habit of leaving a space between the name and the bracketed arguments when typing in his function applications.

For example, he may be typing in Func (args) instead of Func(args). The extra space gets it interpreted as multiplication of Func and (args), ie. Func*(args) in 2D Math input.

acer

I am guessing that he is using 2D Math input and has a habit of leaving a space between the name and the bracketed arguments when typing in his function applications.

For example, he may be typing in Func (args) instead of Func(args). The extra space gets it interpreted as multiplication of Func and (args), ie. Func*(args) in 2D Math input.

acer

Sorry, I hope that the second thread is now linked properly, in the post.

Maybe wolframalpha can give an indication of its strength, using similar examples? It gave a result for,

Integrate[Cos[x]/(1+x^6),x,-infinity,infinity]

but timed out on,

Integrate[Cos[x]/(1+x^8),x,-infinity,infinity]

Now, with a little post-simplification I could obtain in Maple 16.01 a form pretty similar to that which wolframalpha obtained for the first of those two, ie.,

T:=int(cos(x)/(1+x^6),x=-infinity..infinity):

collect(subsindets(simplify(evalc(T),size),
                   specfunc(anything,{sinh,cosh}),
                   t->convert(t,expln)),
        exp(-1/2));

1 /   /1  (1/2)\    (1/2)    /1  (1/2)\\       /-1\   1           
- |cos|- 3     | + 3      sin|- 3     || Pi exp|--| + - Pi exp(-1)
3 \   \2       /             \2       //       \2 /   3           

But if it were using a contour method then I'd have expected Mathematica to get the second example quite quickly.

Is this an area for so-called hybrid symbolic-numeric computation (in the practical sense, as opposed to a grant application sense)? Poles might be found numerically, say.

acer

@LijiH No (edited: by which I mean, if you demand it without I=sqrt(-1))

@LijiH No (edited: by which I mean, if you demand it without I=sqrt(-1))

It's not clear what exactly you're saying. Could you upload a simple example in a worksheet, and clear mark what you think is a 2D Math literal subscript within it, and note the actions that undermine that aspect?

If you are working with summations (function calls to `Sum`, or unevaluated function calls to `sum`) then how can a literal subscript be of any special use? If a name that looks like x-subscript-i is a name with a literal subscript then it will not change as `i` changes. And, inside a `sum` that uses `i` as the index of summation then such an x-subscript-i would be equivalent to a constant.

It is not at all true that the whole point behind literal subscripts is to "make the equations visual." Such a claim makes it unclear whether your understanding of the term agrees with how it is used in Maple. If I misunderstand you then I apologize -- it's hard without an example worksheet. The purpose of a literal subscript is to provide a distinct name which is wholly independent of the base-name. In other words, the purpose is to provide a visually subscripted name which is acted upon as if it were a unique name with no relationship to either the unsubscripted base name or the subscript.

For example, suppose that  was a name with a literal subscript. That means that it is not equal to  when i=0 since that  is its own unique identifier and depends upon neither x nor i, in both a mathematical and a syntactical way. Such a subscripted name is not useful in the usual way if used inside a sum indexed by `i`.

Indexed names, on the other hand, change identity as the value of the index changes. If  is the 2D Math input representing the 1D Maple Notation name x[i] then it changes identity as `i` changes. Just as in 1D, this indexed name is like what usually gets used within a sum indexed by `i`. The whole point of making indexed names be marked up to appear as subscripted names when displayed as 2D Math input is so that some indexed formula is visual (ie. 2D).

acer