Re: Problem with complex integration in Mathematica 7.0.1

*To*: mathgroup at smc.vnet.net*Subject*: [mg121171] Re: Problem with complex integration in Mathematica 7.0.1*From*: Andrew Moylan <amoylan at wolfram.com>*Date*: Fri, 2 Sep 2011 03:29:04 -0400 (EDT)*Delivered-to*: l-mathgroup@mail-archive0.wolfram.com

Hi Tom, This happens because in Mathematica 0.9 + I Infinity and 1.9 + I Infinity are not distinct points, and they both evaluate to same value, namely I*Infinity: In[102]:= 0.9 + I Infinity Out[102]= I Infinity In[103]:= 1.9 + I Infinity Out[103]= I Infinity Of course outside Mathematica they are used as a shorthand notation in integration limits. They are shorthand for this: In[105]:= NIntegrate[f[0.9 + s], {s, -I \[Infinity], I \[Infinity]}] Out[105]= 0. - 3.97173 I In[106]:= NIntegrate[f[1.9 + s], {s, -I \[Infinity], I \[Infinity]}] Out[106]= 2.28367*10^-12 + 2.31145 I Or another way to get the right contour is to insert an intermediate point as you pointed out. Hope this helps! Andrew Moylan Wolfram Research ----- Original Message ----- > From: "Tom D" <tomdickens at att.net> > To: mathgroup at smc.vnet.net > Sent: Thursday, September 1, 2011 3:05:06 AM > Subject: Problem with complex integration in Mathematica 7.0.1 > > In doing some research involving integration in the complex plane, > over vertical contours (inversion of Mellin transforms), I've noticed > an issue with Mathetica 7.0.1. I've done these same calculations in > v3.0 and don't see the same problem. > > I can boil it down to an integration with a single Gamma function as > the integrand. Take f[s_] := Gamma[-s]; since Gamma has poles at > negative integers and 0, f[] will have poles at the positive > integers. > > The problem is that when I specify the infinite vertical contour > using > just the endpoints, the value of the integral does not depend on the > real part of the contour ! However, it must, since the contour is > being moved past the poles oon the real axis. For example, > > In[287]:= f[s_] := Gamma[-s] > > In[288]:= NIntegrate[ > f[s], {s, 0.9 - I \[Infinity], 0.9 + I \[Infinity]}] > > During evaluation of In[288]:= NIntegrate::slwcon: Numerical > integration converging too slowly; suspect one of the following: > singularity, value of the integration is 0, highly oscillatory > integrand, or WorkingPrecision too small. >> > > During evaluation of In[288]:= NIntegrate::ncvb: NIntegrate failed to > converge to prescribed accuracy after 9 recursive bisections in s > near > {s} = > {1.63072643374912722470619778528907451971744544067085196095506521276*10^-29 > I}. NIntegrate obtained 5.04373+146.59 I and 25.32245011719028` for > the integral and error estimates. >> > > Out[288]= 5.04373 + 146.59 I > > In[289]:= NIntegrate[ > f[s], {s, 1.9 - I \[Infinity], 1.9 + I \[Infinity]}] > > During evaluation of In[289]:= NIntegrate::slwcon: Numerical > integration converging too slowly; suspect one of the following: > singularity, value of the integration is 0, highly oscillatory > integrand, or WorkingPrecision too small. >> > > During evaluation of In[289]:= NIntegrate::ncvb: NIntegrate failed to > converge to prescribed accuracy after 9 recursive bisections in s > near > {s} = > {1.63072643374912722470619778528907451971744544067085196095506521276*10^-29 > I}. NIntegrate obtained 5.04373+146.59 I and 25.32245011719028` for > the integral and error estimates. >> > > Out[289]= 5.04373 + 146.59 I > > (* no redo these these integrals adding an intermediate point to the > path, on the real axis *) > > In[291]:= NIntegrate[ > f[s], {s, 0.9 - I \[Infinity], 0.9, 0.9 + I \[Infinity]}] > > Out[291]= 0. - 3.97173 I > > In[290]:= NIntegrate[ > f[s], {s, 1.9 - I \[Infinity], 1.9, 1.9 + I \[Infinity]}] > > Out[290]= -2.28328*10^-12 + 2.31145 I > > Note that when I put in the intermediate point on the real axis (0.9 > or 1.9) I get results that change, as they should, when I move the > path past the pole at s=1, and I don't see the convergence warnings. > Is this a clue as to what is gong on? > > So, does anyone understand why this is happening, or is it a true bug > that should be reported? It really had me confused for a while... > > Thanks, > Tom > >