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

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.5011, 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.5011, 3.5011, 2.4011, 3.4011, 2.51, 3.51, 2.41, 3.41}

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.51*2.1 results in a displayed 0 with Precision yielding not 1, as expected, but 0.69897. Checking further using

{#, Round[#], Accuracy[#], Precision[#]}&/@{2.51, 2.1, 2.51+2.1, 2.51*2.1}


$$\begin{array}{cccc} \bf input& \bf output& \bf Round&\bf Accuracy&\bf Precision\\ 2.51& 2. & 2 & 0.60206 & 1. \\ 2.1& 2. & 2 & 0.69897 & 1. \\ 2.51+2.1& 4. & 4 & 0.346787 & 1. \\ 2.51*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.

• Almost certainly Round is using guard digits, so the ones ending .5011 will round up whereas the ones with .51 will round to even. Commented Jan 24, 2015 at 22:33
• Round[] respects the rounding rules "nearest-to-even" of IEEE 754 (used quite everywhere), while the backtick (aka Precision) does not, albeit in the same application. It looks like a bug to me, since significance is dealt with differently with respect to rounding. Commented Jan 24, 2015 at 22:57
• By the way, if you want Daniel Lichtblau to see your comment response, you should add an @DanielLichtblau tag into your comment, otherwise he will not be alerted to your response. This trick works on any StackExchange site, and is very useful. Commented Jan 25, 2015 at 0:02
• Thx! On the other hand: If anyone is interested, I trust he will be coming back either way - I would rather not pester people, if it can be avoided. Nevertheless: Again: Thank you for sharing this information! :) Commented Jan 25, 2015 at 0:13
• I don't think this is precisely right: "While the explicit precision statement    does round..." It's the FE that typesets 2.51 as a 3.. The value is still 2.51.. One might still consider it a bug (or at least inconsistent), and typesetting is important (for printing reports, say). Commented Jan 25, 2015 at 2:22

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.51, y -> 2.11}


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.61.  *)


Products

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

x*y /. inputs // FullForm
(*  5.250.6989700043360187  *)


Display digits

Note that 2.51 * 2.11 is not in fact 0, but 5.250.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.250.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.

• As to the display digits, there are some cases that confuse me, particularly when it has no digits to display and chooses to display 0.. Others really seem buggy, such as 960 displaying as 1.*10^2 instead of 1.0*10^2
– Rojo
Commented Jan 25, 2015 at 17:38
• @MichaelE2: Thank you for your findings! My "problem" is: Either the Precision`-command is doing "the right thing", or the documentation. It is not that multiplication should in any way change the number of significant digits: If there are two numbers, each with one significant digit, I would expect calculations to be performed like this: Calculate with any digits and then display the result appropriately (and consistently throughout the system) rounded to the minimum of the significant digits of the original values. Commented Jan 25, 2015 at 19:02
• Michael, I would like to merge this question with (29122) if possible. Do you feel that this is reasonable? Commented Jan 25, 2015 at 20:07
• @Mr.Wizard I agree it's a borderline case. I noticed 29122 earlier, and considered whether this should be marked a duplicate. The most significant difference is the connection with how precision is calculated, which was emphasized in the updates to the question. (It is also why I answered.) I wouldn't object to merging the question. Please see my response to Jinxed to follow this one in a few minutes. I think there is an issue to clear up here that has nothing to do with q/29122. See what you think. Commented Jan 25, 2015 at 20:28
• @MichaelE2 Surely it is not a duplicate. Rather I hope that the old question could be edited to include both (all) issues, making it a "canonical reference" for rounding-method-issues in Mathematica. I would appreciate your help with the necessary editing if you feel this is a reasonable goal. Commented Jan 25, 2015 at 20:30