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)