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