Interesting Improper Integrals

Doug Meade's picture

A colleague showed this to me earlier this afternoon. I can explain, and accept, most of Maple's responses. I do have one case where I believe Maple could do better.

This arose during the creation of some Maple materials to support the derivation of the Integral Test for series convergence. Consider:

restart;
I1 := Int( 1/x^p, x=1..infinity );
                                /infinity      
                               |          1    
                               |          -- dx
                               |           p   
                              /1          x    

Asking for the value of the integral, with no assumptions on p, gives:

value( I1 );
                         /   (-p + 1)                  \
                         |  x         - 1              |
                    limit|- -------------, x = infinity|
                         \      p - 1                  /

Good. This result does depend on the value of p.

So, look at three different situations with assumptions on p:

value( I1 ) assuming p>1;   # correct
                                      1  
                                    -----
                                    p - 1

value( I1 ) assuming p=1;   # correct
                                  infinity

value( I1 ) assuming p<1;   # not simplified (cancel p-1 from numer and denom)
                            infinity p - infinity
                            ---------------------
                                    p - 1        

The last result is the intriguing one. I have two questions about this:

  1.  
  2. how does Maple get to this specific form (from I1)?

  3.  
  4. why doesn't Maple simplify this result (under the stated assumption) to infinity?

Of course,

simplify( % );
                                  infinity

It is interesting to see how Maple responds when the improper integral is evaluated without any assumptions

R1 := int( 1/x^p, x=1..infinity );
                         /   (-p + 1)                  \
                         |  x         - 1              |
                    limit|- -------------, x = infinity|
                         \      p - 1                  /

Now, applying the assumptions on p

R1 assuming p>1;            # correct
                                      1  
                                    -----
                                    p - 1

R1 assuming p=1;            # incorrect (but didn't have a chance because antiderivative is incorrect)

                         /   (-p + 1)                  \
                         |  x         - 1              |
                    limit|- -------------, x = infinity|
                         \      p - 1                  /

R1 assuming p<1;            # correct
                                  infinity

The result for p=1 is not surprising as the antiderivative does not apply in this case. But, Maple is able to handle the p<1 case without any trouble.

Here is the complete worksheet with these results

View 178_InterestingInt.mw on MapleNet or Download 178_InterestingInt.mw
View file details

Looking forward to some discussion on this one.

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu       
Phone:  (803) 777-6183         URL:    http://www.math.sc.edu/~meade/

Comments

piecewise output?

One point is whether the integral should be given in piecewise or equivalent form (eg a list). Ie something like this "fabrication":

I1 := Int( 1/x^p, x=1..infinity );
v:=value( I1 );
v1:=subsop(1=limit(op(1,v),p=1),v);
piecewise(p<>1,v,p=1,eval(v1,1));

{                   (-p + 1)
{                  x         - 1
{      lim       - -------------        p <> 1
{ x -> infinity        p - 1
{
{           lim       ln(x)             p = 1
{      x -> infinity

limits

At a point it tries to calculate:

`simplify/power`((1+limit(-x/(p-1)/(x^p),x = infinity)*p
-limit(-x/(p-1)/(x^p),x = infinity))/(p-1));

and simply takes the limits inside the brackets.

This was observed using eg:

infolevel[all]:=3;
trace(int):
trace(`int/cook/nogo1`):
trace(`int/elliptic`):
trace(`simplify/trig`):
trace(`simplify/power`):
trace(`simplify/RootOf`):
printlevel:=5:
acer's picture

observation

Just some observations:

> I1:=int( 1/x^p, x=1..infinity ):

> value( I1 ) assuming p<0;

                                   infinity

> value( I1 ) assuming p<1, p>0;
                                   infinity

> gorp:=value( I1 ) assuming p<1;
                                 infinity p - infinity
                         gorp := ---------------------
                                         p - 1

> eval(gorp,p=1/2);
                                   undefined

> limit(gorp,p=1/2);
                                   infinity

> limit(gorp,p=a) assuming a<1;
                                   infinity

If I had to guess, then I'd wonder whether int() is not taking some limit, in some subcase. Or perhaps it goes to unnecessary trouble just because it does not notice some common behaviour over more than a single subregion (eg. p<0 and 0<p<1). One can see it take longer, and collect garbage, when using only the assumption p<1.

Ok, so I peeked a little. The unsimplified result is obtained by the FTOC integrator. So one could look harder at why IntegrationTools:-Definite:-Integrators:-Asymptotic:-EstimateInternal and friends are not getting the simpler result of `infinity` prior to the FTOC integrator's being used. It is the "Asymptotic" integrator that gets the simple `infinity` result for the assumption p<0. So without looking harder I'll stick with the guess for now, that the Asymptotic integrator gets confused, possibly through not noticing commonality of two regions of interest...

acer

Maple is correct

> `assuming`([int(1/x^p, x = 1 .. infinity)], [p < 1, p > 0]);
 =
                                  infinity

It's correct. Maple probably distinguishes the sign of infinity, so this is why assumption  p>0  produces the

desired result. Or it uses an algorithm, where the sign of p is important.

                                  Sandor

 

Doug Meade's picture

sign of p should not enter the analysis

I beg to disagree.

There is never a case where these integrals are negative. The sign of the answer is never in question. The (real-valued branch of the) integrand is positive for all p.

All that matters is the comparison of p with 1. The integrals converge for p>1 (because 1-p<0) and diverge for p<=1 (with p=1 treated as a special case).

It does appear that, the way Maple does the problem, the sign of p does enter into the picture. But, this is mathematically unnecessary.

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu       
Phone:  (803) 777-6183         URL:    http://www.math.sc.ed

Sign of p

Sorry, I was very short. What you say is mathematically correct. I meant the sign of p. The reason is that without p>0 just using p<1

Maple gives a strange answer, giving the sign of p the result is correct.  In the numerator it uses  p*infinity because does not know

if it is +oo   or  -oo.   But this is only my guess.

                                                                                           Sandor

Doug Meade's picture

simplifying expressions with infinity

I think I understand where you are coming from. At some point Maple gets to the expression:

q := (p*infinity - infinity )/(p-1);
                            p infinity - infinity
                            ---------------------
                                    p - 1

In this form I agree that the sign of p does affect the value. But, there is also a common factor of p-1 in both numerator and denominator that should resolve this issue. Let's look at this expression simplified without any assumptions, and with a few assumptions:


simplify( q );
                                  infinity
simplify( q ) assuming p>0;
                                  undefined
simplify( q ) assuming p=1;
Error, (in assuming) when calling '`is/solve`'. Received: 'numeric exception: division by zero'
simplify( q ) assuming p<1;
                                  infinity
simplify( q ) assuming p>1;
                                  undefined

The last example shows the point you are arguing. When p>1, the numerator is infinity - infinity, which Maple cannot resolve without additional information.

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu       
Phone:  (803) 777-6183         URL:    http://www.math.sc.ed

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
}