Accuracy?

[Valentin Albillo]

(06-18-2021 03:26 PM)Albert Chan Wrote:  Each operation, rounded to 12 digits, is correct.
let fl(x) = rounded-12-digits of x

√(3/7)      → fl(√(fl(3/7)))      = fl(√(0.428571428571))                    = 0.654653670708
√(3)/√(7) →fl(fl(√3) / fl(√7)) = fl(1.73205080757 / 2.64575131106) = 0.654653670710

This is the history of why HP did this way: An interview with WILLIAM M. KAHAN, page 145/146

Quote:TI had this advertisement in the papers. It was a full-page advertisement. It said, “Type in your telephone number. Now,” they said, “Take the logarithm.” The logarithm turns out to be a number form ten-point-something, or nine-pointsomething, actually. “Now hit the exponential key. Do you get your phone number back? You do on our calculator.”

HP was now embarrassed because it appeared that their calculator was somehow defective,
and they were worried about it—I mean, really worried about it ...

I said, “You can do what they [TI] do, except for one thing: in order to be honest, round every result back to ten digits even if you carry thirteen to compute it.” And I said, “If you do that, then each operation, taken by itself, will give you a rather honest answer, and you can explain this log exponential thing. That’s easy because when you take the log, you’ve got the right log. It’s correct to within just a little bit worse than half a unit in the last digit of the display. Then you can say ‘Now, it’s that error that propagates when you take the exponential because, if we recovered your telephone number, we’d be getting the exponential not of the number that you see before you. It would have to be the exponential of something else.’’

After many decades of using HP models implementing Kahan's philosophy, I'd take TI's 13-digit over HP's 10-digit any day, because though Kahan's may be right for the unwashed masses of key-pushers, a power user can (and usually does) get additional precision by cleverly using those 3 extra, hidden digits.

To add insult to injury, that the (for example) HP-71B computes like this:

>1/3+1/3+1/3

.999999999999 (12 digits)

despite doing computations internally with 15-digit accuracy is simply unforgivable. Giving the final result to 12 digits, disregarding the 3 extra digits, is bad enough, but also converting to 12-digit each *intermediate* result (which the user never sees, it's all internal, so no need to convert it to 12-digit), thus losing accuracy wholesale (imagine a longer expression, using functions) is simply unforgivably wasteful and wholly uncalled for.

The proper way to do it is obvious: compute every intermediate result to 15 digits and deliver the final result to 12. That way 1/3+1/3+1/3 gets evaluated internally as .999999999999999 (15 digits) and then returned as exactly 1 (12 digits). Doing otherwise is a bad case of "Kahan"-itis.

V.