Accuracy?

06182021, 09:44 AM
(This post was last modified: 06182021 10:13 AM by HansB.)
Post: #1




Accuracy?
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)) 

06182021, 03:26 PM
Post: #2




RE: Accuracy?
Each operation, rounded to 12 digits, is correct.
let fl(x) = rounded12digits 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 fullpage advertisement. It said, “Type in your telephone number. Now,” they said, “Take the logarithm.” The logarithm turns out to be a number form tenpointsomething, or ninepointsomething, actually. “Now hit the exponential key. Do you get your phone number back? You do on our calculator.” 

06182021, 04:04 PM
Post: #3




RE: Accuracy?
(06182021 03:26 PM)Albert Chan Wrote: Each operation, rounded to 12 digits, is correct. After many decades of using HP models implementing Kahan's philosophy, I'd take TI's 13digit over HP's 10digit any day, because though Kahan's may be right for the unwashed masses of keypushers, 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) HP71B computes like this: >1/3+1/3+1/3 .999999999999 (12 digits) despite doing computations internally with 15digit accuracy is simply unforgivable. Giving the final result to 12 digits, disregarding the 3 extra digits, is bad enough, but also converting to 12digit each *intermediate* result (which the user never sees, it's all internal, so no need to convert it to 12digit), 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. All My Articles & other Materials here: Valentin Albillo's HP Collection 

06182021, 05:01 PM
(This post was last modified: 06182021 06:19 PM by HansB.)
Post: #4




RE: Accuracy?
(06182021 04:04 PM)Valentin Albillo Wrote: [....] 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. 

06182021, 05:13 PM
Post: #5




RE: Accuracy?
Interesting, in the Python console
1/3+1/3+1/3 gives 1.0 

06182021, 05:16 PM
Post: #6




RE: Accuracy?
[/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 

06182021, 06:40 PM
Post: #7




RE: Accuracy?  
06182021, 09:51 PM
Post: #8




RE: Accuracy?
(06182021 05:01 PM)HansB Wrote: HP Prime does the same Prime Home uses the same floatingpoint format (12digit BCD, 15 digits internally) as all Saturnbased 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. 

06182021, 10:02 PM
Post: #9




RE: Accuracy?
(06182021 06:40 PM)Steve Simpkin Wrote:(06182021 04:04 PM)Valentin Albillo Wrote: ... LOL.... Excellent! A twist I never saw coming... and I'm both a Trekkie and HP geek... Bob Prosperi 

06192021, 02:47 AM
Post: #10




RE: Accuracy?
(06182021 10:02 PM)rprosperi Wrote:(06182021 06:40 PM)Steve Simpkin Wrote: Kahan!!! Exactly the same here, you wrote my own reply for me. +1 !! Best regards. V. All My Articles & other Materials here: Valentin Albillo's HP Collection 

06192021, 03:07 PM
Post: #11




RE: Accuracy?
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. 

06192021, 05:46 PM
(This post was last modified: 06192021 05:47 PM by Mike Elzinga.)
Post: #12




RE: Accuracy?
(06192021 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. 

« Next Oldest  Next Newest »

User(s) browsing this thread: 1 Guest(s)