WOLFRAM

Services & Resources / Wolfram Forums / MathGroup Archive

MathGroup Archive 2004

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

Search the Archive

Re: Re: Re: Integrate in version 5.1

The G5 does NOT have the same processor as the G4 :) So it is NOT just 
the speed.
János
On Dec 17, 2004, at 5:18 AM, Andrzej Kozlowski 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
>>
>>
----------------------------------------------
Trying to argue with a politician is like lifting up the head of a 
corpse.
(S. Lem: His Master Voice)
  • Prev by Date: Re: Plotting a function of an interpolated function
  • Next by Date: File association in 5.01
  • Previous by thread: Re: Re: Integrate in version 5.1
  • Next by thread: Re: Re: Integrate in version 5.1