Re: Re: Re: Integrate in version 5.1

*To*: mathgroup at smc.vnet.net*Subject*: [mg52968] Re: [mg52928] Re: [mg52910] Re: [mg52880] Integrate in version 5.1*From*: János <janos.lobb at yale.edu>*Date*: Sat, 18 Dec 2004 03:59:42 -0500 (EST)*References*: <200412150927.EAA10723@smc.vnet.net> <200412160841.DAA27360@smc.vnet.net> <200412171018.FAA16041@smc.vnet.net>*Sender*: owner-wri-mathgroup at wolfram.com

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)

**References**:**Integrate in version 5.1***From:*ab_def@prontomail.com (Maxim)

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

**Re: Re: Integrate in version 5.1***From:*Andrzej Kozlowski <akoz@mimuw.edu.pl>

**Re: Plotting a function of an interpolated function**

**File association in 5.01**

**Re: Re: Integrate in version 5.1**

**Re: Re: Integrate in version 5.1**