5
$\begingroup$

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?

$\endgroup$
1
  • 1
    $\begingroup$ 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. $\endgroup$
    – Michael E2
    Aug 17, 2016 at 11:51

2 Answers 2

4
$\begingroup$

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.

$\endgroup$
1
  • $\begingroup$ 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. $\endgroup$
    – Michael E2
    Aug 17, 2016 at 11:27
2
$\begingroup$

Some remarks, not a complete answer:

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

Yields as last calculation:

RealDigits[9.2195444572928873100022742817627931572468050487224640080077522054426710
26801875460767894090793280564940339808878871684152124663346517172`101., 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.

$\endgroup$
5
  • $\begingroup$ 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 85`100) and y = Sqrt[x] increases precision by one bit (dy/y = dx/2). $\endgroup$
    – Michael E2
    Aug 17, 2016 at 11:54
  • $\begingroup$ @MichaelE2 Does it make sense for precision to not be an integer? I.e., will it actually potentially cause a different rounding? $\endgroup$
    – Feyre
    Aug 17, 2016 at 12:25
  • $\begingroup$ 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.59`2. vs. 1.59`2.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. $\endgroup$
    – Michael E2
    Aug 17, 2016 at 13:28
  • 1
    $\begingroup$ 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. $\endgroup$
    – Michael E2
    Aug 17, 2016 at 13:30
  • $\begingroup$ No, it's clear, thanks for the explanation. $\endgroup$
    – Feyre
    Aug 17, 2016 at 15:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.