Re: Re: Integrate in version 5.1
- To: mathgroup at smc.vnet.net
- Subject: [mg52935] Re: [mg52910] Re: [mg52880] Integrate in version 5.1
- From: DrBob <drbob at bigfoot.com>
- Date: Fri, 17 Dec 2004 05:19:00 -0500 (EST)
- References: <200412150927.EAA10723@smc.vnet.net> <200412160841.DAA27360@smc.vnet.net> <EDE6166A-4F64-11D9-A3F7-000A95B4967A@mimuw.edu.pl>
- Reply-to: drbob at bigfoot.com
- Sender: owner-wri-mathgroup at wolfram.com
Wait just a darn minute...
You're saying two computers with the same operating system and Mathematica version can get different results from Integrate depending on PROCESSOR SPEED?
Yikes!!!!
Bobby
On Thu, 16 Dec 2004 22:18:09 +0900, Andrzej Kozlowski <akoz at mimuw.edu.pl> wrote:
>
>
> All this seems to mean is that, as Maxim pointed out, you have a fast
> computer. In agreement with Maxim's observation I have the problem on
> my 1 GHZ PowerBook but not on a 2 GHZ G5.
>
> That suggests an interesting problem. Is there anyway in suhc cases for
> the Kernel to obtain information about the processor that is being
> used, so as to set the TimeConstraint in a way that depends on the
> speed of the machine? An alternative approach would be to run a very
> short test program and then use TimeConstraint depending on the
> system's perfomrance in the test.
>
> The assumption here is that people with slower machines would have
> learned to be more patient and would not mind waiting longer to
> increase the chances of getting correct answers ;-)
>
> Andrzej Kozlowski
>
>
> On 16 Dec 2004, at 17:41, DrBob wrote:
>
>>>> 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
>>
>
>
>
>
--
DrBob at bigfoot.com
www.eclecticdreams.net
- References:
- Integrate in version 5.1
- From: ab_def@prontomail.com (Maxim)
- Re: Integrate in version 5.1
- From: DrBob <drbob@bigfoot.com>
- Integrate in version 5.1