Re: Re: Simple question or how Mathematica getting on my nerves.
- To: mathgroup at smc.vnet.net
- Subject: [mg45957] Re: [mg45894] Re: Simple question or how Mathematica getting on my nerves.
- From: Daniel Lichtblau <danl at wolfram.com>
- Date: Fri, 30 Jan 2004 04:17:18 -0500 (EST)
- References: <butdvt$9se$1@smc.vnet.net> <200401291034.FAA09674@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
Vladimir Bondarenko wrote:
> gtsavdar at auth.gr (George) wrote in message news:<butdvt$9se$1 at smc.vnet.net>...
>
>>Although the 2 results must be the same they aren't. WHY???????
>>And not only this, but they differ by 10^21!!!!!! WHY????????
>
>
>
> Hello,
>
> I have a remark to the answers given by Msr Hanlon, Rowe, Noffke,
> Kozlowski and Treat whose many comment I agree with, and two
> questions about the Mathematica overall design.
>
> There are at least 2 commercial applications where the things go
> smoothly in the case at hand. I respect the request of our
> moderator Steven Christensen and not name those applications
> but the fact remains:
>
>
>>evalf(int(2687176093959399272413585923303421161600*(1-f)^67*f^61, f = .6214 .. .5242));
>>evalf(int(2687176093959399272413585923303421161600*(1-f)^67*f^61, f = 6214/10000 .. 5242/10000));
>
>
> -.1398383104
> -.1398383104
>
> APPROX(INT(2687176093959399272413585923303421161600*(1-f)^67*f^61, f,
> 6214/10000,5242/10000))
> APPROX(INT(2687176093959399272413585923303421161600*(1-f)^67*f^61, f,
> 0.6214, 0.5242))
>
> -0.1398383104
> -0.1398383104
>
>
> while for Mathematica we see
>
>
> Integrate[2687176093959399272413585923303421161600*(1 - f)^67*f^61,
> {f, 0.6214, 0.5242}]
>
> -9.37972 10^21 (* Mathematica 5.0 *)
> -9.2522 10^21 (* Mathematica 4.2.1 *)
> -7.82732 10^21 (* Mathematica 3.0 *)
> 1.03892 10^23 (* Mathematica 2.2 *)
>
> I believe all of you would agree that treating the above results
> yielded by those application as pure coincidence would set before
> us a formidable challenge as the chances such random behavior
> would be some 1/10^20; thus, it's not by chance.
>
> My questions are,
>
> 1) Why exactly none Mathematica version can operate in a similar way?
>
> 2) Suppose, the above behavior is a feature. Had Mathematica been
> designed in a way supporting the behavior of those two
> systems, what would be the headaches inferred from such
> hypothetical design?
>
>
> Best wishes,
>
> Vladimir Bondarenko
>
> GEMM architect
> Co-founder, CEO, Mathematical Director
> Cyber Tester, LLC
>
> http://www.cybertester.com/
> http://www.CAS-testing.org/
>
> .......................................................................
I do not recognize the second language used (maybe a version of
Maxima/Macsyma?), but as results are similar to that of the first I'll
restrict attention to that one. I'll try to respond to the following two
questions (related but not identical to the two raised above).
What is it that Maple9 is doing in the case of inexact vs. exact input?
Why is Mathematica doing otherwise?
First, one can set an environmental variable to learn that Maple9 is
using a quadrature method for the inexact example, and a form of
Newton-Leibniz integration for the exact case. As I do not much care for
reverse engineering, I'll not pursue this further.
Mathematica is using a symbolic method in both cases. It will use
quadrature only when either invoked from NIntegrate, or by
N[Integrate[...]] where the integral was not evaluated already by
symbolic means.
The rationale is that Integrate is meant to invoke symbolic (rather than
numeric) methods. As has been explained, in this example the error from
cancellation and roundoff in the evaluation of the antiderivative
overwhelm the eventual numeric computation. One can do better by
enforcing higher precision, e.g. as:
In[17]:= Integrate[2687176093959399272413585923303421161600*(1-f)^67*f^61,
{f, SetPrecision[0.6214,100], SetPrecision[0.5242,100]}]
Out[17]= -0.13983831041675672833888136585253987917689010455473864094441
Another issue I might point out is that there are examples for which
numeric quadrature is quite slow, whereas symbolic methods are both fast
and reliable. In such cases it is nice to have the option of using the
latter. Hence I would argue that the different semantics of Integrate vs
NIntegrate are a good thing (of course it helps that the latter has
various Method and related options that can affect speed, accuracy, and
so forth). Here is an example where I think Mathematica is doing
something "useful" and striking a reasonable balance in terms of method
chosen (that is, both speed and quality of result are reasonable).
Integrate[2687176093959399272413585923303421161600*(1-f+a)^67*f^61,
{f, SetPrecision[0.6214,100], SetPrecision[0.5242,100]}] /. a->21
Out[20]//InputForm=
-8.87442862314275223217725952037724623337936273758312617635936751900310922312\
56972203062497225293492505031266497687`96.57701318005357*^113
This compares favorably to the quadrature result below.
NIntegrate[2687176093959399272413585923303421161600*(1-f+21)^67*f^61,
{f, 0.6214, 0.5242}]
Out[23]//InputForm= -8.87442862314275*^113
Needless to say, this all involves design decisions, and people might
argue in favor of different directions from those WRI has taken. I
simply wished to offer a brief explanation of the rationale behind ours.
Daniel Lichtblau
Wolfram Research
- References:
- Re: Simple question or how Mathematica getting on my nerves.
- From: vb@cybertester.com (Vladimir Bondarenko)
- Re: Simple question or how Mathematica getting on my nerves.