Is the divergence between Round and setting an explicit precision intentional or a bug?

Question

Introductory remark: I take it (from Mathematica's online documentation), that Precision is effectively the number of significant digits, as seen by the system.

• For literals, precision is set using backquotes, e.g. 2.501`1, which yields a 3.. Calling Precision on this result gives 1, as expected.

• On the other hand, there is Round, which, well, rounds according to the unbiased next-to-even-scheme, e.g.:

  $\quad \quad $Round[{2.501, 3.501, 2.401, 3.401, 2.5, 3.5, 2.4, 3.4}]

  gives the integers

  $\quad \quad ${3, 4, 2, 3, 2, 4, 2, 3}

But:

$\quad \quad ${2.501`1, 3.501`1, 2.401`1, 3.401`1, 2.5`1, 3.5`1, 2.4`1, 3.4`1}

yields an unexpected difference at the 5th position:

$\quad \quad ${3., 4., 2., 3., 3., 4., 2., 3.}

So, specifying a precision explicitly (which should be a number of significant digits, according to documentation), gives different results than rounding the same literals to the same number of significant digits.

While the explicit precision statement ` does show the number rounded, its method is not next-to-nearest-even, but the biased next-to-larger-absolute (i.e. "up-from-0.5").

My question therefore is:

Did I miss some of the intricacies of the assorted norms or should Mathematica round the same, regardless of how the number of significant digits is specified (Round or `1 (* or more, according to magnitude before the decimal separator *))?

Further findings

2.5`1*2.`1 results in a displayed 0 with Precision yielding not 1, as expected, but 0.69897. Checking further using

{#, Round[#], Accuracy[#], Precision[#]}&/@{2.5`1, 2.`1, 2.5`1+2.`1, 2.5`1*2.`1}

which leads to

$$ \begin{array}{cccc} \bf input& \bf output& \bf Round&\bf Accuracy&\bf Precision\\ 2.5`1& 2. & 2 & 0.60206 & 1. \\ 2.`1& 2. & 2 & 0.69897 & 1. \\ 2.5`1+2.`1& 4. & 4 & 0.346787 & 1. \\ 2.5`1*2.`1& 0. & 5 & 0. & 0.69897 \\ \end{array} $$

adds to my confusion about the semantics of significant digits in Mathematica.

Reference: NumericalPrecision

---

Extension/Background for the Question

The reason for me asking this question is, that I wanted to implement calculations with Mathematica, which obey the rule, that any (final) results shall be displayed with the minimum number of significant digits of all values/measurements used as input.

After consulting the documentation, I thought, that setting an input value's precision explicitly would have been the key to this.

Now, however, I am at a loss, since

1. the rounding behavior of the frontend differs from Round
2. arithmetic operations like multiplications change the precision of the result in forseeable, but practically less usable ways.

Obviously, I will have to turn to the hard way and track the number of significant digits myself and round as appropriate using Round.

Answer 1

According to Precision, the precision of a number x with absolute uncertainty dx is p -> -Log10[dx / x]. Conversely the uncertainty is given by dx -> x * 10^-p.

For a calculation f[x, y, ...], the precision is estimated by Dt[f[x, y, ...] / f[x, y, ...], where Dt[x] represents the uncertainty of x and so on for any other variables. I'll show that for the sum and product, this formula gives the precision exactly as computed by Mathematica for the OP's inputs:

inputs = {Dt[x] -> 2.5*10^-1, Dt[y] -> 2.1*10^-1, x -> 2.5`1, y -> 2.1`1}

Thus the behavior of precision and accuracy will be seen to be entirely consistent with the theory and the design of Mathematica. I'll then explain a little about how the FE displays numbers, but I don't know enough to give a full explanation.

Sums

-Log10[Dt[x + y]/(x + y) /. inputs] // FullForm
(*  1.  *)

x + y /. inputs // FullForm
(*  4.6`1.  *)

Products

-Log10[Dt[x*y]/(x*y) /. inputs] // FullForm
(*  0.6989700043360187  *)

x*y /. inputs // FullForm
(*  5.25`0.6989700043360187  *)

Display digits

Note that 2.5`1 * 2.1`1 is not in fact 0, but 5.25`0.69.... It is just typeset as 0.. To display the first digit (of this number between 1 and 10), we should have an uncertainty less than dx = 1. or an Accuracy of at least -Log10[dx] == 0. But the uncertainty is

5.25*10^-0.6989700043360187` 
(*  1.05  *)

and the accuracy is

-Log10[1.05]
5.25`0.6989700043360187 // Accuracy
(*
  -0.0211893
  -0.0211893
*)

To get one digit we need at least a precision p given by the following:

NSolve[5.25*10^-p == 1]
(*  {{p -> 0.720159}}  *)

This is the borderline value. In this particular case, a slightly higher precision (p + 4.47741*10^-15) is needed to get the FE to display the first digit 5. I don't know why.

I also do not know what the FE is supposed to do when it rounds. On a logarithmic scale, 2.5 is closer to 3. than 2., but I've never seen an argument for (or against) rounding on that basis. Rounding away from zero (Wikipedia) has a completely different justification. As I said in a comment, it seems odd not to be consistent with Round.