@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.

@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))