# Strange RealDigits rounding behavior with N

The last two digits of N[Sqrt[85], 101] are 49, but the last term of RealDigits[N[Sqrt[85], 101], 10, 100] is 5, where I expect it to be 4. Changing 101 to 102 or larger number results in 4, which is expected. Why does this happen?

• Changing 101 to 102 changes the number you're computing the digits of....Different input, different output is certainly possible. See Coolwater's answer for a reason why the first answer should end in a 5. Aug 17, 2016 at 11:51

Evaluating Interval[N[Sqrt[85], 101]] you will see that due to the uncertainty of floating point numbers, the exact number that is being approximated by N[Sqrt[85], 101] could just as well have 5 as its 100th digit.

Hence RealDigits is only well-defined up to and including the 99th digit. In upcoming versions the 100th digit may change between 4 or 5.

• Another spin on it: What the OP's RealDigits[..] command is computing is not the digits of Sqrt[85], but the digits of a number near it. And that number is closer to the 100-digit result ending in a 5 than the one ending in a 4. Aug 17, 2016 at 11:27

Some remarks, not a complete answer:

Trace[RealDigits[N[Sqrt[85], 101], 10, 100]]


Yields as last calculation:

RealDigits[9.2195444572928873100022742817627931572468050487224640080077522054426710
26801875460767894090793280564940339808878871684152124663346517172101., 10, 100]


The value has more digits, so the rounding that N[] is producing in '101 is somehow carried over in RealDigits.

A better way to run this would be to actually trim the precision before passing the calculation over to RealDigits.

RealDigits[SetPrecision[Sqrt[85], 101], 10, 100]


Yields the expected result.

• Note that SetPrecision[Sqrt[85], 101] has a precision greater than 101. It is equivalent to N[Sqrt[85], 101 + Log10[2]], because SetPrecision sets the precision of the numbers in an expression (i.e. 85 becomes 85100) and y = Sqrt[x] increases precision by one bit (dy/y = dx/2). Aug 17, 2016 at 11:54
• @MichaelE2 Does it make sense for precision to not be an integer? I.e., will it actually potentially cause a different rounding? Aug 17, 2016 at 12:25
• Yes, I think it does make sense for two reasons. One is somewhat trivial: The computations are all done in binary and the precision is defined to be -Log[10, dx/x] which will be whatever number it is. The other is that it would cause a difference in rounding, in both output and internal computations. For output, it's easy to demonstrate: 1.592. vs. 1.592.3 For input, it's much harder to demonstrate. Arbitrary precision keeps a finite but unknown (to me) number of extra guard bits, so an internal rounding difference would be rare and normally confined to the guard bits. Aug 17, 2016 at 13:28
• An ill-conditioned example of an internal rounding difference: SeedRandom[0]; data = (-1)^Range[10^6] RandomReal[{1, 101/100}, 10^6, WorkingPrecision -> 10]; prec = 6; Print@InputForm@Total[N[data, prec]]; Print@InputForm@Total[N[data, prec + 0.3]]...But maybe I didn't understand you. The principal use of precision is not to control rounding but to keep track of bounds on rounding error in a computation. Aug 17, 2016 at 13:30
• No, it's clear, thanks for the explanation. Aug 17, 2016 at 15:26