The Museum of HP Calculators

HP Forum Archive 19

 Accuracy by chanceMessage #1 Posted by Javier Goizueta on 7 Oct 2009, 4:19 a.m. Recently, while testing various implementations of arbitrary-precision decimal trigonometry, I came up with seemingly excellent results of the Savage test due to less than perfect trigonometry. By chance, error cancellation worked better with some imperfect implementations than it did with correctly rounded results. This reminded me of the apparent accuracy of the HP-35s trigonometry (leaving apart its known bugs!) so I took a look at it. The result of the forensic test for the HP-35s (a 12 digit calculator without hidden precision) is 8.99999986001 (1.56E-6 percent error) while the HP Saturn-based 12 digits calculators (HP-71B, 28*, 48*, 42s, etc.) give 8.99999864267 (1.51E-5 percent error.) So, is the trigonometry of the 35s better than that of the venerable Saturn models? The answer is no: in each step of the test the Saturn calcs give the best possible answer to within 12 digits, so no other 12-digit calculator (with no hidden precision) can possibly be better in this particular case. The good result of the 35s occurs purely by chance. When it comes to compute the ATAN, both calcs have the argument 1.74549998555E-2, which has accumulated some round-off error deviating from the perfect 1.74549998554886...E-2 result (computed with unlimited precision). The ATAN of the 12-digits argument is 0.9999962727435345... which is correctly rounded by Saturn calcs to 0.999996272744, while the 35s gives the not-so-correct 0.999996272743. But by chance some of the accumulated error has now cancelled and the final result is better; the unlimited precision result of ATAN(TAN(COS(SIN(9)))) is 0.999996272742885...). This tiny deviation fully explains the final result of the test. Note that the forensics test is a great easy way of identifying families of calculators, and was never intended to measure accuracy. In general, we should be aware of the randomnes in the results of tests that accumulate rounding error which makes them not a valid measure of accuracy in any particular case. Take for example the Gruenberger test that I applied to the SmartCalc 300S in this thread If we compute it with perfectly rounded 14-digit arithmetic, the result is worse than using 13 digits. The best result with 25 digits is worse than the best result with 23 digits! Well, after all, the Saturn models' accuracy remains unsurpassed! ... and the 35s trigonometry is not only buggy, but not-so-accurate as well.

 Re: Accuracy by chanceMessage #2 Posted by Gerson W. Barbosa on 7 Oct 2009, 10:13 a.m.,in response to message #1 by Javier Goizueta Quote:Well, after all, the Saturn models' accuracy remains unsurpassed! ... and the 35s trigonometry is not only buggy, but not-so-accurate as well. You're right, but rather than microprocessors better algorithms have played an import role to achieve that accuracy. I think you are aware of this old thread, started by Rodger Rosenbaum, in which he quotes the philosophy behind math routines in HP calculators after the influence of Prof. Kahan: "Each calculation is to return a result as though the calculation were done to infinite precision and the result properly rounded (round to even on most Saturn calcs) to an n-digit result." The HP-33C and the HP-34C are the oldest calculator I have which achieve this goal. It appears newer HP calculators have abandoned this philosophy, so they will not give the expected forensic result. However at least the 12C Platinum has been programmed to replicate it: ```1) asin(acos(atan(tan(cos(sin(9)))))): Keystrokes Display 9 9. R/S 0.156434465 g GTO 090 R/S 0.999996273 g GTO 100 R/S 0.017455000 g GTO 178 R/S 0.999996272 g GTO 157 R/S 0.156441660 g GTO 137 R/S 9.000417403```

 Re: Accuracy by chanceMessage #3 Posted by Paul Dale on 7 Oct 2009, 4:55 p.m.,in response to message #2 by Gerson W. Barbosa My long running and slowly progressing scientific 20b firmware fares well in this particular test: ``` 9.000000000029361 ``` Which, if you reference the old thread mentioned above, is correct for 16 digits :-) - Pauli

 Re: Accuracy by chanceMessage #4 Posted by Gerson W. Barbosa on 7 Oct 2009, 5:31 p.m.,in response to message #3 by Paul Dale Quote: ```9.000000000029361 ``` Which, if you reference the old thread mentioned above, is correct for 16 digits :-) Way to go! That's exactly what I get on the 200LX: ```1.564344650402309e-1 0.999996272742885 1.745499985548866e-2 0.999996272742885 1.56434465040737e-1 9.000000000029361 ``` A 20b with your firmware should be fantastic. I only hope the keys are good enough. Gerson.

 Re: Accuracy by chanceMessage #5 Posted by Walter B on 7 Oct 2009, 6:48 p.m.,in response to message #4 by Gerson W. Barbosa Quote: A 20b with your firmware should be fantastic. I only hope the keys are good enough. Well, we try our very best. Though tactile response is given by the 20b as is.

 Re: Accuracy by chanceMessage #6 Posted by Jeff O. on 8 Oct 2009, 1:27 p.m.,in response to message #3 by Paul Dale Quote: My long running and slowly progressing scientific 20b firmware... Pauli, Have you provided any/many details regarding your 20b scientific firmware project? I checked the archives, there was some discussion last Fall, and a couple of mentions in threads since then, but no details. So I went to the 20b repurposing web site, and found this page where you described your efforts to create a scientific calculator on the 20b: Quote: The calculator is based loosely on the HP-34c with some of the more modern functions added; it also has complex operations like the 32/35 series but over a much wider range of functions. Additionally, the device supports superset of the HP-16c integer mode functionality. It is programmable with 500 steps of program memory (every instruction taking but a single step) and 100 storage registers. The above sounds pretty cool. That page was last updated on 2008/12/21. Unfortunately, the links on that page are broken, but with a little guessing I found them: Any updates on the above or other details regarding your project?

 Re: Accuracy by chanceMessage #8 Posted by Jeff O. on 9 Oct 2009, 8:20 a.m.,in response to message #7 by Paul Dale Thanks for the update. It sounds pretty awesome.

 Re: Accuracy by chanceMessage #9 Posted by Walter B on 8 Oct 2009, 7:53 p.m.,in response to message #6 by Jeff O. If you tell me a place where I can put some 600kB of pdf, I'll be happy to upload edition 1.8 of the documentation file tomorrow.

 Re: Accuracy by chanceMessage #10 Posted by Jeff O. on 9 Oct 2009, 8:11 a.m.,in response to message #9 by Walter B I guess your guest folder here is too full? To clear room in mine, I have gone back and subsituted smaller images for the originals. That way there is still an image in the archives and not the annoying:

 Re: Accuracy by chanceMessage #11 Posted by Walter B on 9 Oct 2009, 9:31 a.m.,in response to message #10 by Jeff O. AFAIK, nobody but Dave is allowed to upload files greater than 100kB on this site. This makes perfect sense, since at the golden age of our objects of worship, 64kB was what an entire data acquisition system for e.g. nuclear spectroscopy needed. So, sorry, no way to upload 600kB here. Waiting for a better offer, Walter

 Re: Accuracy by chanceMessage #12 Posted by Jeff O. on 9 Oct 2009, 10:18 a.m.,in response to message #11 by Walter B Walter, I was just able to upload a 123 kB file. But this may not be the best place to host your manual. Jeff

 Re: Accuracy by chanceMessage #13 Posted by Karl Schneider on 9 Oct 2009, 1:46 a.m.,in response to message #2 by Gerson W. Barbosa Hi, Gerson -- Quote: The HP-33C and the HP-34C are the oldest calculator I have which achieve this goal (of returning a result correct to n significant digits, given input assumed to be accurate to n significant digits) Almost, but with at least one exception: Trigonometrics with small-magnitude results that reside within the guard digits. The HP-34C -- and every other subsequent scientific model (HP-41C/CV/CX, HP-10C, HP-11C, HP-15C) until the Saturn processor -- will return ```sin (3.141592653 rad) = 5.9E-10, instead of 5.897932385E-10. ``` My explanation for this result is this excerpt from the following thread: HP calculators with pre-Saturn microprocessors (e.g., HP-15C) and many modern calculators from other manufacturers (e.g, TI-82) sometimes give only two significant digits for the sine and cosine calculations described. I suspect that they calculate out to their internal precision of three guard digits, round the answer to the second guard digit and "call it good", without recognizing that even more digits could be calculated due to the small magnitude of the result. Example: ``` input |guard| extra \ / sin 3.14159265358|000| = 0.00000000000|979|323846264 | | ``` On any Pioneer-series model and some descendants, you get 9.79323846264e-12 as the result. On some newer 12-digit non-HP's, you might get 9.8e-12 as the result. Quote: It appears newer HP calculators have abandoned this philosophy, so they will not give the expected forensic result. I don't believe that the "philosophy was abandoned". However, the standard was certainly not met in some cases due to errors in porting ROM code to modern microprocessors, and the lack of rigorous testing that was done in the past. To my knowledge, all the identified transcedental-math errors of the HP-33s and HP-35s have been corrected -- except perhaps for the trig error discussed in the linked thread, which was corrected for the HP-20b. As for giving highly-accurate forensic results, it's impossible without carrying many extra digits of precision in the calculations -- three is not enough. -- KS Edited: 9 Oct 2009, 2:24 a.m.

 Re: Accuracy by chanceMessage #14 Posted by Gerson W. Barbosa on 9 Oct 2009, 5:25 p.m.,in response to message #13 by Karl Schneider Hello Karl, Quote: Quote: The HP-33C and the HP-34C are the oldest calculator I have which achieve this goal (of returning a result correct to n significant digits, given input assumed to be accurate to n significant digits) Almost, but with at least one exception: Trigonometrics with small-magnitude results that reside within the guard digits. The HP-34C -- and every other subsequent scientific model (HP-41C/CV/CX, HP-10C, HP-11C, HP-15C) until the Saturn processor -- will return ```sin (3.141592653 rad) = 5.9E-10, instead of 5.897932385E-10. ``` Yes, almost is the word that was missing in my statement. Thanks for the correction! (an 's' was also missing :-) Quote: To my knowledge, all the identified transcedental-math errors of the HP-33s and HP-35s have been corrected -- except perhaps for the trig error discussed in the linked thread, which was corrected for the HP-20b. I wish it had been corrected on the 33s also, even though it doesn't affect my calculations. Currently that is the replaceable HP calculator I use most. The '1' key on my second unit got broken after only two years of not so heavy use. The same had happened on my first one ('.' key). Quote: As for giving highly-accurate forensic results, it's impossible without carrying many extra digits of precision in the calculations -- three is not enough. I assume by highly-accurate forensic results you mean results very close to 9. If such is the case three guard digits are really too little. But if each intermediate result is to be rounded to the number of digits of the display then three is enough - at least for the particular 9 degrees argument. Regards, Gerson.

Go back to the main exhibit hall