MathGroup Archive 2002

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

Search the Archive

Re: RE: RE: Accuracy and Precision

  • To: mathgroup at smc.vnet.net
  • Subject: [mg37001] Re: [mg36989] RE: [mg36936] RE: Accuracy and Precision
  • From: Daniel Lichtblau <danl at wolfram.com>
  • Date: Sun, 6 Oct 2002 05:32:38 -0400 (EDT)
  • References: <200210040901.FAA04692@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

This had been an exchange in private e-mail. But it seems to have made a
leap to MathGroup so I'll respond there as well to some of the issues
raised herein.

DrBob wrote:
> 
> Daniel,
> 
> >>The precision/accuracy tracking mechanism will generally let you know,
> >>in some fashion, that you have no trustworthy digits. But it is up to
> >>the user to check that sort of thing.
> 
> In this case Mathematica did NOT let us know, in any fashion, that we
> had no trustworthy digits.  Precision and Accuracy outputs were
> completely misleading.  (16 and -5 respectively.) 

Precision, in this case, is itself a bit misleading. As I recall machine
arithmetic was in use. For that domain just regard 16 as the definition
of precision. Moreover no tracking is done. It is only when bignums are
used that significance arithmetic will be at play.

By the way, the distinction between precision for machine numbers vs.
bignums will be more clear with our next big release. At present one
does not know if 16 refers to a machine number or a bignum of that same
precision.


> Even Andrzej
> Kozlowski, who's adept in Mathematica, thought that would be meaningful,
> and never came up with a better way to check (other than using infinite
> precision for numbers that probably aren't known that exactly).  Peter
> Kosta demonstrated that he could get a completely erroneous answer with
> Infinite precision.
> 
> I blame the problem primarily, and I don't think there's any way to make
> the answer meaningful.  That's not Mathematica's fault at all, and users
> need to be aware of that old maxim: "garbage in, garbage out".

Right. One cannot artificially raise precision or accuracy after the
fact and expect a meaningful result. Again, had significance arithmetic
been used, I think there would have been adequate information to assess
the problem.


> Still, if the Kernel adds 37-digit numbers with 16-digit precision and
> comes up with a 22-digit result, it doesn't take much sophistication to
> realize the answer can't have 16-digit precision.
> 
> Here's an even more extreme result:
> 
> f = SetAccuracy[333.75*b^6 + a^2*(11*a^2*b^2 - b^6 -
>         121*b^4 - 2) + 5.5*b^8 + a/(2*b), 50];
> a = 77617.; b = 33096.;
> f
> Precision[f]
> 
> -1.180591620717411303424`71.0721*^21
> 71
> 
> 71.0721 digits of precision?  I don't think so!!
 
It's correct, albeit the number is garbage. You start with a number that
is, in your words, "all noise". (I assume you had set a and b before f,
because otherwise I get a different result for Precision[f]). Now
f ~ 10^21, and so has accuracy of around 71 digits. Garbage
notwithstanding, this behavior is entirely correct and as it should be.


> We can do the following instead:
> 
> x = Interval[333.75];
> y = Interval[5.5];
> a = Interval[77617.];
> b = Interval[33096.];
> x*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + y*b^8 + a/(2*b)
> 
> Interval[{-4.486248158726164*^22, 4.2501298345826815*^22}]
> 
> and that looks like the right answer, finally!!  I like that method.

Yes, it's a useful way to show that the result has no digits to trust.
Actually you can achieve a similar effect using significance arithmetic,
as below.

x = SetPrecision[33375/100, 16];
y = SetPrecision[11/2, 16];
a = SetPrecision[77617, 16];
b = SetPrecision[33096, 16];

In[18]:= InputForm[x*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + y*b^8
+ a/(2*b)]
Out[18]//InputForm= -1.1339143158169`0*^14

This tells you there are NO reliable digits. The advantage to this is
that is is more flexible than interval arithmetic in Mathematica which
will not, for example, deal well with complex-valued functions or
complex domains. Also significance arithmetic (aka "arbitrary precision"
arithmetic) is much faster than interval arithmetic for large problems.


> However, that doesn't change the fact that Accuracy, Precision, and
> SetAccuracy appear to be completely useless.

My own experience is that they are quite useful. But only if used with
care and in appropriate ways. Raising accuracy after the fact does not
fall into that category.


> I haven't seen an example
> in which they did what anyone (but you) thought they should do.
> 
> Bobby

Maybe. But, curiously enough, I am a user rather than developer when it
comes to that stuff. I used the precision mechanism alot in polynomial
NSolve, and it did indeed work to my liking. Which counts for something
from the ordinary users' perspective, because now NSolve works better
than it otherwise might.


> -----Original Message-----
> From: danl at wolfram.com [mailto:danl at wolfram.com]
To: mathgroup at smc.vnet.net

(Ahem), when I check my "Sent" mailbox it shows:


> Subject: [mg37001] [mg36989] Re: [mg36936] RE: Accuracy and Precision
> 
> DrBob wrote:
> >
> > I think I'd prefer that Mathematica gave me a clue -- without being
> > asked explicitly in JUST the right way that only you know and had
> > forgotten -- that there's a precision problem.
> >
> > Oddly enough, when you DO ask it nicely, you get error messages, but
> if
> > you're not aware there's a problem, it lets you go on your merry way,
> > working with noise.
> >
> > Bobby
> 
> Mathematica is not a mind reader. But the evaluation sequence, while
> complicated, is reasonably well documented. If you perform machine
> arithmetic, or for that matter significance arithmetic, and there is
> massive cancellation error, no use of SetAccuracy after the fact will
> fix it.
> 
> The precision/accuracy tracking mechanism will generally let you know,
> in some fashion, that you have no trustworthy digits. But it is up to
> the user to check that sort of thing. It is not obvious to me what sort
> of "error" the software might notice to report. If you have a concise
> example of input, and expected output, I can look further. I've not seen
> anything in this thread that struck me as a failure of the software to
> warn the user, but maybe I missed something.
> 
> Daniel


Daniel Lichtblau
Wolfram Research


  • Prev by Date: Re: Re: Accuracy and Precision
  • Next by Date: Re: Significance Arithmetic
  • Previous by thread: RE: RE: Accuracy and Precision
  • Next by thread: Re: Re: Accuracy and Precision