Re: Re: Integrate in version 5.1
- To: mathgroup at smc.vnet.net
- Subject: [mg52954] Re: [mg52910] Re: [mg52880] Integrate in version 5.1
- From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
- Date: Fri, 17 Dec 2004 05:20:33 -0500 (EST)
- References: <200412150927.EAA10723@smc.vnet.net> <200412160841.DAA27360@smc.vnet.net> <EDE6166A-4F64-11D9-A3F7-000A95B4967A@mimuw.edu.pl> <opsi3urax5iz9bcq@monster.ma.dl.cox.net>
- Sender: owner-wri-mathgroup at wolfram.com
I don't think this is surprising and in fact probably inevitable.
Until version 5 Integrate did not use Simplify. It used to be quite
common that Integrate would leave a certain expression unevaluated but
if you first applied Simplify to it, it would successfully manage to
integrate it. This phenomenon completely disappeared in version 5.
Obviously now Integrate is using Simplify. But as we know, the time
Simplify will take to complete its job is unpredictable; it could be
impossibly long. So obviously if you are going to automatically use
Integrate[Simplify[expr}...] you would want to use the option
TimeConstraint, otherwise not only will you get even more complaints
about slowdowns compared with previous versions but you will find that
certain integrals that Mathematica could previously manage now seem to
take "infinitely long". But once you use TimeConstraint you run into
the problem discovered by Maxim, sometimes a fast machine will manage
to finish simplifying an expression within the time constrain while a
slower one will not. This will almost certainly result in a different
answer. In principle there could be several kinds of different answers:
they may only differ in the form but be actually equal if one applies
Simplify, it may happen that Mathematica will not be able to evaluate
an integral on a slower machine which it can manage on a faster one, or
the answers may actually be different. One would normally expect the
result of integrating Simplify[expr] to be more likely to be correct
than integrating expr directly, but since Simplify also has some bugs
in it it may even happen that integrating without simplifying will give
the right answer while after simplifying one gets a wrong one. This
seems to account for some of the integrals that Mathematica 4 used to
get right but Matheamitca 5 got wrong.
Anyway, the difference between fast and slow machines is certainly a
bad thing. What one need is a TimeConstraint function but measured not
in seconds but in terms of the processors internal clock, in other
words in something which I think is called "ticks". I do not know about
this enough to judge if this is possible. If not than one can perhaps
run small tests to check the speed of the computer. Probably the best
thing would be for Mathematica to run such a test the first time
Integrate was used, after which the results of the test could be used
in evaluating all subsequent integrals. This should make it possible to
give every machine approximately equivalent amount of time to complete
simplification and would at least reduce the likelihood of getting
different results on different CPUs.
Andrzej
On 16 Dec 2004, at 23:34, DrBob wrote:
> *This message was transferred with a trial version of CommuniGate(tm)
> Pro*
> 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:
>
>>
>>
>> *This message was transferred with a trial version of CommuniGate(tm)
>> Pro*
>> 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:
>>
>>> *This message was transferred with a trial version of CommuniGate(tm)
>>> Pro*
>>>>> 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