Mathematica 9 is now available
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

Re: Integrate in version 5.1

  • To: mathgroup at smc.vnet.net
  • Subject: [mg52910] Re: [mg52880] Integrate in version 5.1
  • From: DrBob <drbob at bigfoot.com>
  • Date: Thu, 16 Dec 2004 03:41:23 -0500 (EST)
  • References: <200412150927.EAA10723@smc.vnet.net>
  • Reply-to: drbob at bigfoot.com
  • Sender: owner-wri-mathgroup at wolfram.com

>> Also there still exist some examples where reevaluating the same
>> expression leads to a different outcome:

I get the same answer for both integrals with 5.1 -- (2*Pi*r^3)/3 -- with either ClearCache OR Quit beforehand.

Bobby

On Wed, 15 Dec 2004 04:27:40 -0500 (EST), Maxim <ab_def at prontomail.com> wrote:

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



-- 
DrBob at bigfoot.com
www.eclecticdreams.net


  • Prev by Date: Re: Delete problem
  • Next by Date: Re: Re: Intersection of two surfaces in 3D
  • Previous by thread: Integrate in version 5.1
  • Next by thread: Re: Re: Integrate in version 5.1