Precision vs accuracy in displaying result of numerical calculation

Questions
1

(1-Sqrt[1^2\4\(.000001)])/(2\)

(1 - Sqrt[1^2 \[Minus] 4 \[Pi] (.000001)])/(2 \[Pi])

HP50g gives the numeric value as 1.00000313421E-6 and when the numerator is rationalized to

(2\(.000001))/(1+Sqrt[1^2\4\(.000001)])

(2*(.000001))/(1 + Sqrt[1^2 \[Minus] 4 \[Pi] (.000001)])

the HP50g gives the numeric value as 1.00000314161E-6. both are the same equation but you get two different answers on the HP50g calculator. I wanted to see what Mathematica would do with these equations but only got 1.x10^-6 for both answers. I tried using ‘N’ to 12 digits of precision but just got the same answer as before. After half an hour of stumbling around I found SetPrecision and SetAccuracy. They also give two different answers to the same equations. For me Help is of little help and I could not understand the difference between the two functions as they are synonyms in most dictionaries. Which is more accurate--no, which is more precise--no, which is the more correct answer is what I am asking as i have four different answers to the same equation???

1.000003141606536172730042*10^-6
1.000003141612392770285595*10^-6
1.000003141606536173*10^-6
1.0000031416123927703*10^-6

and if possible - why does Mathematica like the HP50g calculator produce different answers to equivalent equations??

2

The reason for seeing just 1.x10^-6 is that by default the FrontEnd displays only 6 digits for machine precision numbers.
This setting can be changed in the preferences, or one could use InputForm to see the whole number:

In[1]:= (1 - Sqrt[1 - 4 Pi 0.000001])/(2 Pi) // InputForm

Out[1]//InputForm= 1.0000031416065362*^-6

In[2]:= (2*(.000001))/(1 + Sqrt[1 - 4 Pi (.000001)]) // InputForm

Out[2]//InputForm= 1.0000031416123928*^-6

Out[1] and Out[2] being slightly different is due to floating point error. In particular, Out[1] is worse because of cancellation error.

If we use exact arithmetic, by replacing the machine number .000001 with 10^-6, we can calculate as many digits of precision as we want and both results will agree:

In[3]:= N[(1 - Sqrt[1 - 4 Pi 10^-6])/(2 Pi), 300]

Out[3]= 1.0000031416123929536281643215075828386566143402859978591686401018873720\
3179897969705146376944882602668522205013133800117219790268808485400485\
8840108639520376207821817998162553187367331834187818008320352763966480\
1322401710099760862898966185163178923486730652394778912768503218857690\
2219961386285260497*10^-6

In[4]:= N[(2 10^-6)/(1 + Sqrt[1 - 4 Pi 10^-6]), 300]

Out[4]= 1.0000031416123929536281643215075828386566143402859978591686401018873720\
3179897969705146376944882602668522205013133800117219790268808485400485\
8840108639520376207821817998162553187367331834187818008320352763966480\
1322401710099760862898966185163178923486730652394778912768503218857690\
2219961386285260497*10^-6
3

Thanks Ilian, that was very helpful knowing that floating decimals can create problems in calculations.

Also wondering about difference between precision and accuracy… when would I use one over the other, is there a difference in their application???

In the below screen shot, why did Mathematica evaluate SetPrecision first, then SetAccuracy second, and InputForm last??? That is very confusing as that is not the input order of the functions to be evaluated…

ScreenShot2014-01-09at12.45.27PM.png
ScreenShot2014-01-09at12.45.27PM.png469×183 11.6 KB

4

Another question on this subject, since the HP50g fiqured in the original question. On the HP50g in exact mode
pic1.jpg
On input this immediately (without user action) simplifies to
pic2.jpg

On the HP, converting this expression to an approximate real nunber gives
pic3.jpg

It differs from Mathematicas approximate real number representation of the original expression
1139pic4.jpg

My question: Which of the two reals is the most “exact” ?

5

Subtracting two floating point numbers close to each other leads to loss of significance. This is a feature of floating point arithmetic, the calculator will also give a more accurate result provided one uses the second formula that avoids the cancellation. For the correct answer, see the above 300 digit computation.

The three numbers in Raymond’s post are only correct up to 1.0000031416. The reason is that the entire computation is done with machine precision and calling SetPrecision afterwards will only pad with (binary) zeros. There will be more digits in the result, but they will not be reliable, because we have started with a machine number. A little better, but far from optimal (correct only up to 1.0000031416123929) is

In[4]:= (1 - Sqrt[1 - 4 Pi SetPrecision[0.000001, 35]])/(2 Pi)

Out[4]= 1.0000031416123929083759918187152063*10^-6

Compare with N, which works adaptively to obtain the desired precision:

In[5]:= N[(1 - Sqrt[1 - 4 Pi 10^-6])/(2 Pi), 35]

Out[5]= 1.0000031416123929536281643215075828*10^-6

The difference between precision and accuracy is that the former measures relative, and the latter absolute uncertainty (error). If x0 is the true value, and x an approximation, the precision satisfies Abs[(x-x0)/x0] == 10^-prec, while the accuracy satisfies Abs[x-x0] == 10^-acc. Precision can therefore be thought of as the approximate number of significant digits, while accuracy is the approximate number of significant digits to the right of the decimal point.

Perhaps the following blog post and the resources mentioned there, particularly this tutorial from the documentation, will be of interest. For a really in-depth look, I would recommend this article: Sofroniou, M., & Spaletta, G. (2005). Precise numerical computation. Journal of Logic and Algebraic Programming, 64(1), 113-134.

6 
Rationalize[(1 - 
    Sqrt[1^2 \[Minus] 4 \[Pi] (.000001)])/(2 \[Pi]), 10^-16]

106/105999667
7

106/105999667

This approximation has only the following digits correct: 1.000003141. A better rational approximation would be e.g. 78914926117188/78914678197856987665.

8 
Rationalize[(1 - 
    Sqrt[1^2 \[Minus] 4 \[Pi] (.000001)])/(2 \[Pi]), 10^-1000]

75595/75594762511
9

It looks like this is a bug:

SetAccuracy[{.123456, .00001}, 5]

ScreenShot2022-06-04at2.03.00PM.png

Should it be 0.0000 for the second example?

10

Effectively SetAccuracy[0.00001] is 0.0000. It just doesn’t format that way. Add 1 to see something along the lines you might expect.

11

It still looks buggy!

SetAccuracy[{.123456, .987654, .00002}, 5] + 1 // FractionalPart

ScreenShot2022-06-06at12.52.26PM.png

12

No bug. Again, that’s just how bignum approximate zeros get formatted.

13

A number like 0. \times 10^{-5} indicates that the uncertainty is greater than the absolute value of the number and the uncertainty is around 10^{-5}.

If the precision is less than 0.5 (inferred from trials), then the number is highlighted in pink.

Examples of borderline cases to give a start to those who wish to experiment:

0.00002`0.3010299 (* 0.3010299 < Log10[2.] *)
0.00002`0.30103 (* 0.30103 > Log10[2.] *)

0.00002`0.49999 (* 0.49999 < 0.5 *)
0.00002`0.5

0.00004`0.60205999 (* 0.60205999 < Log10[4.] *)
0.00004`0.60206 (* 0.60206 > Log10[4.] *)