Accuracy?

[HansB]

Why does my Prime G2 shows different results with equal inputs? I like to understand how accurate to how many digits Prime calculates, and how many digits will be displayed. It appears I cannot trust the last digit displayed.
For instance (all textbook input, standard number format, results grouped here for better readability):

Code:

sqrt(3/4)      -> 0.866 025 403 784    (cos(30))
sqrt(3)/2      -> 0.866 025 403 785
phone calculator: 0.866 025 403 784 438 6...

sqrt(3/7)       -> 0.654 653 670 708
sqrt(3)/sqrt(7) -> 0.654 653 670 71
phone calculator:  0.654 653 670 707 977 1...

cubicroot(3/8) -> 0.721 124 785 154
cubicroot(3)/2 -> 0.721 124 785 155
phone calculator: 0.721 124 785 153 704 1...

[Albert Chan]

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.’’

[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.

[HansB]

(06-18-2021 04:04 PM)Valentin Albillo Wrote:  [....]
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.

I agree. HP Prime does the same
1/3+1/3+1/3 -> .999999999999 (12 digits)
(unless you use CAS view).

So does the Prime work internally to 15 digits, but rounds every intermediate and the end result to 12 digits? Why?
So we get accumulating errors in the twelfth digit, and, when several computations are involved, possibly also in the eleventh and perhaps even the tenth digit.
Estimating a possible error would be like:
+-1 in the last (twelfth) digit, multiplied by the number of calculation steps. Something to bear in mind, especially if many calculating steps are involved, as can happen in a program loop.

[rampo]

Interesting, in the Python console
1/3+1/3+1/3
gives 1.0

[rampo]

[/quote]

I agree. HP Prime does the same
1/3+1/3+1/3 -> .999999999999 (12 digits)
(unless you use CAS view).

So does the Prime work internally to 15 digits, but rounds every intermediate and the end result to 12 digits? So we get accumulating errors in the twelfth digit, and this twelfth digit cannot be trusted?
[/quote]

Interesting, in the Python console
1/3+1/3+1/3
gives 1.0

[Steve Simpkin]

(06-18-2021 04:04 PM)Valentin Albillo Wrote:  ...

Doing otherwise is a bad case of "Kahan"-itis.

V.

Kahan!!!

   

[John Keith]

(06-18-2021 05:01 PM)HansB Wrote:  HP Prime does the same
1/3+1/3+1/3 -> .999999999999 (12 digits)
(unless you use CAS view).

So does the Prime work internally to 15 digits, but rounds every intermediate and the end result to 12 digits? Why?

Prime Home uses the same floating-point format (12-digit BCD, 15 digits internally) as all Saturn-based HP calculators since the 71B. Prime CAS uses the more common 64 bit binary floating point format, but integers and rational numbers are exact, like the 50g exact mode.

[rprosperi]

(06-18-2021 06:40 PM)Steve Simpkin Wrote:  

(06-18-2021 04:04 PM)Valentin Albillo Wrote:  ...

Doing otherwise is a bad case of "Kahan"-itis.

V.

Kahan!!!

LOL.... Excellent! A twist I never saw coming... and I'm both a Trekkie and HP geek...

[Valentin Albillo]

(06-18-2021 10:02 PM)rprosperi Wrote:  

(06-18-2021 06:40 PM)Steve Simpkin Wrote:  Kahan!!!

LOL.... Excellent! A twist I never saw coming... and I'm both a Trekkie and HP geek...

Exactly the same here, you wrote my own reply for me. +1 !!

Best regards.
V.

[Mike Elzinga]

For those of us who used to be proficient with slide rules, the standard technique to limited digit precision is to rescale the problem to smaller units. For example, instead of joules, use electron volts; or instead of meters, use angstroms or nanometers.

Taking logarithms amounted to finding a mantissa for a number between 0 and 1 and adding the appropriate characteristic.

The main issue underlying the proper use of a calculating instrument such as the slide rule is the same issue with any other calculating device. Having a nice computer or calculator doesn’t eliminate the problem of having to rescale. The more powerful the device, the more complex the problems one can solve, provided one learns the techniques that were forced upon those who once used slide rules.

Knowing how to use proper math techniques makes any calculating instrument far more useful.

[Mike Elzinga]

(06-19-2021 03:07 PM)Mike Elzinga Wrote:  Taking logarithms amounted to finding a mantissa for a number between 0 and 1 and adding the appropriate characteristic.

I should have said that logarithms on the slide rule and in tables were for numbers between 1 and 10. There were several scales that allowed going between common logs and natural logs as well as square roots and cube roots.

By the way, slide rules went extinct in less than a year once handheld calculators came out. The big advantage to calculators was that they could also add and subtract. Adding and subtracting required another set of techniques of regrouping calculations to maintain precision. For example, don't mix very small numbers with very large numbers when adding or subtracting.

I don't miss my slide rule; especially after HP started introducing its calculators.