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

**References**:**RE: RE: Accuracy and Precision***From:*"DrBob" <drbob@bigfoot.com>