Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2004
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2004

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

Search the Archive

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




  • Prev by Date: Re: Re: Simple question or how Mathematica getting on my nerves.
  • Next by Date: RE: Question: formatting text, sections
  • Previous by thread: Re: Simple question or how Mathematica getting on my nerves.
  • Next by thread: Re: Re: Simple question or how Mathematica getting on my nerves.