Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2004
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2004

[Date Index] [Thread Index] [Author Index]

Search the Archive

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


  • Prev by Date: Re: Intersection of two surfaces in 3D
  • Next by Date: Re: Re: Solve Feature?
  • Previous by thread: Re: Re: GUIKit - ScrollPane Tables within Wizard
  • Next by thread: Re: Integrate in version 5.1