Re: RE:Working Precision

*To*: mathgroup at smc.vnet.net*Subject*: [mg23980] Re: [mg23928] RE:Working Precision*From*: David Withoff <withoff at wolfram.com>*Date*: Sun, 18 Jun 2000 03:01:03 -0400 (EDT)*Sender*: owner-wri-mathgroup at wolfram.com

Actually, the relationship between the original NIntegrate example and the Do[x=2*x-x, {100}] example is somewhat tenuous, except that both behaviors follow from general numerical analysis. > I think this is the explanation: > when you have workingprecision-> 16 you are using > normal double precision floats, which behave as you > more or less expect. > > When you set higher working precision, you get WRI's > made-up numerical world of non-standard arithmetic, > in which precision and accuracy may be apparently > lost every time you do arithmetic. Whoever wrote > NIntegrate fell into one of these traps. To see how this > can hurt you, try > x=1.11111111111111111111 > Do[x=2*x-x, {100}] > If[x==x+1, "You must be running Mathematica"] > > Regards, > Richard Fateman > > Bernd Brandt wrote: > > > > Dear members, > > > > Is someone able to explain why Accuracy and Precision > > decrease when i increase WorkingPrecision ? > > > > In: > > ni = NIntegrate[x Sqrt[x], {x, 0, 25}, AccuracyGoal -> 6, > > PrecisionGoal -> 6, > > WorkingPrecision -> 16, Compiled -> False] > > > > In: Accuracy[ni] > > Precision[ni] > > > > Out: 13 > > Out: 16 > > > > In: ni - 1250 > > OUt: -1.506340140622342*10^-6 > > > > Doing the same with WorkingPrecision->32 will yield: > > Accuracy[ni] returns 3 > > Precision[ni] returns 7 > > And: ni-1250 now is less accurate: -0. 10^-4 > > > > Thank you, > > Bernd Brandt Both of the NIntegrate results satisfy the requested error tolerances (they both satisfy PrecisionGoal->6) so there is no problem in that regard. The open question is why the result with WorkingPrecision->16 appears to give a few digits beyond the requested error tolerance, while the result with WorkingPrecision->32 does not. The answer is that standard error analysis is specifically designed to give an upper bound to the uncertainty in a result. Although the actual error is normally less than this upper bound, NIntegrate is designed (except when using machine numbers) to report only the digits that fall within that upper bound, and that are thereby known to be correct. With machine numbers there is no choice but to report 16 digits, since with machine numbers the precision is fixed at 16 digits. In the NIntegrate example with WorkingPrecision->16 the last 7 reported digits are wrong. The result using WorkingPrecision->32 also contains a few extra digits that happen to be correct. You can expose those digits using SetPrecision, which reveals essentially the same difference as the machine-number result. In[1]:= ni = NIntegrate[x Sqrt[x], {x, 0, 25}, PrecisionGoal->6, WorkingPrecision->32] Out[1]= 1250.000 In[2]:= SetPrecision[ni, 15] - 1250 Out[2]= -1.56723 10^-6 The other example: > x=1.11111111111111111111 > Do[x=2*x-x, {100}] > If[x==x+1, "You must be running Mathematica"] illustrates a different effect. This example is a demonstration of standard propogation of error. When error is estimated by computing an upper bound to the error at each step in a calculation, the estimated error in the result can accumulate to be significantly larger than the actual error. This strategy for estimating the error in a result is really the only sensible way of doing this sort of thing. Although the particular implementation of this strategy in Mathematica is unique, the basic idea has been around for centuries. This example essentially just shows an effect of standard methods for propogation of error. The relative newcomer here is fixed-precision machine arithmetic, which is popular primarily because it is easy to implement it on computers, and so (at least for now) it is usually faster and more compact than arithmetic that provides for proper propogation of error. Although these are clearly important considerations, the disadvantage of machine arithmetic is that it can and often does give completely wrong answers without warning, and not just in contrived examples like this one. With machine arithmetic, you are normally obligated to figure out by some independent method which digits are correct. Although not related to the original NIntegrate example, it is worth mentioning that there are situations, such as in algorithms that have been specifically optimized for fixed-precision arithmetic, or calculations in which the errors are strongly correlated, where standard methods for propogation of error can dramatically over-estimate the error in a result. That is what happens in the Do[x=2*x-x, {100}] example, which effectively adds and subtracts the same number, so the error in each addition is perfectly correlated with a compensating error in each subsequent subtraction. In such cases it can be useful to consider some other strategy for estimating error. Fixed-precision arithmetic provides one possible strategy. Unlike standard methods for propogation of error, which assume that all errors are uncorrelated, fixed-precision arithmetic effectively assumes that all errors are perfectly correlated and never accummulate. In the Do[x=2*x-x, {100}] example this is a valid assumption. This effect can be achieved in Mathematica using x=1.11111111111111111111 $MinPrecision = $MaxPrecision = Precision[x] Do[x=2*x-x, {100}] If[x==x+1, "You must be doing standard propogation of error", "You must be using fixed-precision arithmetic"] The overwhelming majority of practical calculations, however, aren't like this. In most cases, treating all errors as uncorrelated is a fairly accurate assumption. Dave Withoff Wolfram Research

**Re: Fast (compiled) routine for element testing and replacement in large matrices?**

**Re: RE:Working Precision**

**RE:Working Precision**

**Re: RE:Working Precision**