Integrate in version 5.1

*To*: mathgroup at smc.vnet.net*Subject*: [mg52880] Integrate in version 5.1*From*: ab_def at prontomail.com (Maxim)*Date*: Wed, 15 Dec 2004 04:27:40 -0500 (EST)*Sender*: owner-wri-mathgroup at wolfram.com

In version 5.1: In[1]:= Integrate[1/z, {z, z1, z2}] Out[1]= (-z1 + z2)*If[Re[z1/(z1 - z2)] >= 1 || Re[z1/(-z1 + z2)] >= 0 || Im[z1/(-z1 + z2)] != 0, (Log[z1] - Log[z2])/(z1 - z2), <<1>>] In a way this is a step back: Mathematica 5.0 generated a condition that described the positions of the points z1, z2 such that the segment [z1, z2] and the branch cut of Log[z] do not intersect (although there was an error in the case of one of the endpoints z1, z2 lying on the branch cut). Now the condition in Out[1] just specifies that [z1, z2] doesn't go through the origin; thus Out[1] is incorrect for any values of z1, z2 such that [z1, z2] intersects the ray (-Infinity, 0), e.g. z1=-1-I and z2=-1+I. But then I fail to see any point in generating a condition at all, if this condition is not generically valid. Many of the typical integration bugs of version 5.0 are still present in 5.1: In[2]:= Integrate[DiracDelta''[x^2 - 1]*x^2, {x, -Infinity, Infinity}] Out[2]= -3/4 The correct value is -1/4. This is not a single bug; replacing the integrand with DiracDelta''[x^2 - 1]*phi[x] shows that the result doesn't contain the terms with phi'', and pretty much all the integrals with higher derivatives of DiracDelta will come out wrong. Applying FunctionExpand to the integrand fixes the problem. It is strange that even some kernel crash issues haven't been fixed, as with NIntegrate[PolyLog[2, E^(-I*y - 1)], {y, 0, 2*Pi}], which crashes the kernel in versions 5.0 and 5.1. Also there still exist some examples where reevaluating the same expression leads to a different outcome: In[3]:= Developer`ClearCache[] Assuming[r > 0, Integrate[Sqrt[r^2 - x^2 - y^2], {x, -r, r}, {y, -Sqrt[r^2 - x^2], Sqrt[r^2 - x^2]}]] Assuming[r > 0, Integrate[Sqrt[r^2 - x^2 - y^2], {x, -r, r}, {y, -Sqrt[r^2 - x^2], Sqrt[r^2 - x^2]}]] Out[4]= (-2*Pi*r^3)/3 Out[5]= (2*Pi*r^3)/3 This is a very regrettable bug, because it will affect many standard integrals over circular regions. What makes this example so peculiar is that the outcome depends on the hardware. I've tried this example on two different systems, both running Mathematica 5.1 for Windows: on Pentium II 450 this glitch is always reproducible, but on Athlon 64 3800 I always get the correct result. The explanation may be quite simple: if somewhere in the integration code there is a line like Simplify[expr, TimeConstraint -> 5], then a slow machine doesn't have enough time to simplify the expression and the integration (or taking the limit or some other complex operation) proceeds with the unsimplified integrand for which the integration gives a wrong result. On a fast machine the integrand is reduced to a simple form, and then the integration works fine. This also explains why the second try on a slow machine works correctly: it uses cached results, thus saving time to advance the simplification further. Sometimes the changes in the new version break previously working code: Integrate[ (-x2 y1 + x3 y1 + x1 y2 - x3 y2 - x1 y3 + x2 y3)* UnitStep[-x2 y1 + x3 y1 + x1 y2 - x3 y2 - x1 y3 + x2 y3], {x1, 0, 1}, {x2, 0, x1}, {x3, 0, x2}, {y1, 0, 1}, {y2, 0, 1}, {y3, 0, 1}] The calculus`integration package could handle this integral (it took approximately 45 seconds on a slow PC), but Mathematica 5.1 locks up on it -- it generates $RecursionLimit::reclim messages and is still running after 20 minutes. The irony is that calculus`integration is no longer included in version 5.1. Next, working with a similar integrand, NIntegrate[ Abs[-x2 y1 + x3 y1 + x1 y2 - x3 y2 - x1 y3 + x2 y3], {x1, 0, 1}, {x2, 0, 1}, {x3, 0, 1}, {y1, 0, 1}, {y2, 0, 1}, {y3, 0, 1}, MaxPoints -> 10^6, PrecisionGoal -> 3] took about 30 seconds in version 5.0 (with or without calculus`integration). Mathematica 5.1 again is unable to evaluate this integral in 20 minutes. The reason is that Mathematica 5.0 assumed that specifying the option MaxPoints always implied the use of the method QuasiMonteCarlo for numerical integration. Now, version 5.1 has two new methods, EvenOddSubdivision and SymbolicPiecewiseSubdivision, for numerical integration of piecewise functions (Abs in this case) and Mathematica seems to apply one of them here. Two possible workarounds are either to specify Method->QuasiMonteCarlo explicitly or to rewrite Abs[z] as Sqrt[z^2], avoiding the piecewise handling routine. The documentation, section A.9.4, still claims that "if an explicit setting for MaxPoints is given, NIntegrate by default uses Method->QuasiMonteCarlo." This appears to be incorrect for version 5.1. The reference for NIntegrate still enumerates only the methods that existed in version 5.0, and the only way to learn about the two new methods is by stumbling on the NIntegrate::bdmtd message. Besides, I just do not see any reason to change the behaviour of NIntegrate in this particular case: MaxPoints meant that I wanted to use stochastic methods, why was it necessary to change this? Maxim Rytin m.r at inbox.ru

**Follow-Ups**:**Re: Integrate in version 5.1***From:*DrBob <drbob@bigfoot.com>

**Re: Intersection of two surfaces in 3D**

**Re: Re: Solve Feature?**

**Re: Re: GUIKit - ScrollPane Tables within Wizard**

**Re: Integrate in version 5.1**