Accuracy by chance « Next Oldest | Next Newest »

 ▼ Javier Goizueta Unregistered Posts: 25 Threads: 9 Joined: Aug 2007 10-07-2009, 04:19 AM 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. ▼ Gerson W. Barbosa Unregistered Posts: 2,761 Threads: 100 Joined: Jul 2005 10-07-2009, 10:13 AM 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``` ▼ Paul Dale Unregistered Posts: 3,229 Threads: 42 Joined: Jul 2006 10-07-2009, 04:55 PM 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 ▼ Gerson W. Barbosa Unregistered Posts: 2,761 Threads: 100 Joined: Jul 2005 10-07-2009, 05:31 PM 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. ▼ Walter B Unregistered Posts: 4,587 Threads: 105 Joined: Jul 2005 10-07-2009, 06:48 PM 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. Jeff O. Unregistered Posts: 875 Threads: 37 Joined: Jul 2005 10-08-2009, 01:27 PM 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? ▼ Paul Dale Unregistered Posts: 3,229 Threads: 42 Joined: Jul 2006 10-08-2009, 07:02 PM Those links are to a very old version of the project but most of the high level ideas haven't changed. There has been a bit of to and fro over the function set since this revision. Mostly new functions added. There have also been a lot of bug fixes and space savings. The software isn't currently running on the 20b hardware but I can compile it for the arm and there is still sufficient space (RAM and flash) left to do the hardware driving that will be required (some of this is done already but more is required). Does anyone know where to source a programming cable from? Any space left over after that will be dedicated to more functionality and bug fixes :-) Highlights are still similar to what I wrote previously: 500 merged programming steps. 100 registers (+ stack X Y Z T L & I). HP-41 like programming model. Almost all operations support complex numbers done like the 35s. Logical and bit operations are a superset of the 16c. Bases supported are from 2 to 16 inclusive, arithmemtic modes are unsigned, ones complement, twos complement and sign and mantissa. Comprehensive suite of statistical operations. Time, date and calendar operations (using the internal RTC for current time and date). Fraction mode as per the 32sii with a maximum denominator of 9999. Walter's documentation change list might be helpful (some of the special characters here will like get mangled): 1.2 4.1.09 Added ASRN, CBC?, CBS?, CCB, SCB, FLOAT, MIRROR, SLN, SRN, >BIN, >DEC, >HEX, >OCT, BETA, D>R, DATE, DDAYS, D.MY, M.DY, Y.MD, CEIL, FLOOR, DSZ, ISZ, D>R, R>D, EMGAM, GSB, LNBETA, LNGAMMA, MAX, MIN, NOP, REAL, RJ, W and WINV, ZETA, %+ and %-; renamed the top left keys B, C, and D, and bottom left EXIT. 1.3 17.1.09 Added AIP, ALENG, ARCL, AROT, ASHF, ASTO, ATOX, XTOA, AVIEW, CLA,PROMPT (all taken from 42S), CAPP, FC?C, FS?C, SGMNT, and the …# commands; renamed NBITS to BITS and STOWS to WSIZE; specified the bit commands closer; deleted the 4 carry bit operations. 1.4 10.2.09 Added CONST and a table of constants provided, D>J and J>D, LEAP?, %T, RCL and STO 􀁣 and 􀁤, and 2 forgotten statistics registers; deleted CHS, EMGAM, GSB, REAL and ZETA; purged and renamed the bit operations; renamed many commands. 1.5 5.3.09 Added RNDINT, CONV and its table, a memory table, the description of XEQ B, C, D to the operation index, and a and ge to the table of constants; put CLSTK on a key, moved CLΣ and FILL, changed the % and log labels on the keyboard, put CLALL in X.FCN; checked and cleaned alpha mode keyboard and added a temporary alpha keyboard; rearranged the alphabet to put Greek after Latin, symbols after Greek consistently; separated the input and non programmable commands; cleaned the addressing tables. 1.6 12.8.09 Added BASE, DAYS+, DROP, DROPY, E3OFF, E3ON, FC?F, FC?S, FIB, FS?F, FS?S, GCD, LCM, SETDAT, SETTIM, SET24, SINC, TIME, VERS, αDAY, αMONTH, αRC#; %Σ, as well as F-, t-, and χ2-distributions and their inverses; reassigned DATE, modified DENMAX, FLOAT, αROT, and αSHIFT; deleted BASE arithmetic, BIN, DEC, HEX, and OCT; updated the alpha keyboards; added flags in the memory table; included indirect addressing for comparisons; added a paragraph about the display; updated the table of indicators; corrected errors. 1.7 9.9.09 Added P.FCN and STAT catalogues, 4 more conversions, 3 more flags, Greek character access, CLFLAG, DECOMP, DENANY, DENFAC, DENFIX, Iβ, IΓ, αDATE, αRL, αRR, αSL, αSR, αTIME, 12h, 24h, fraction mode limits, normal distribution and its inverse for arbitrary μ and σ, and Boolean operations working within FLOAT; deleted αROT and αSHIFT, the timer, and forced radians after inverse hyperbolics; renamed WINV to W –1, and beta and gamma commands to Greek; added tables of catalogue contents; modified label addressing; relabeled PRGM to P/R and PAUSE to PSE; swapped SHOW and PSE as well as Δ% and % on the keyboard; relabeled Q; corrected CEIL and FLOOR; There have been a number of changes since the 1.7 documentation. Mostly extra statistic distributions -- currently, normal(0,1), normal(mean,var), chi^2, t, F, geometric, Weibull, binomial, poisson & exponential both cumulative distribution functions and their inverses. The operations that aren't supported in complex mode are those that don't make sense, those that won't fit on the stack (regularized incomplete beta function), the integer mode only commands and a couple of other functions: error function and regularized incomplete gamma function - but not the normal gamma function. Complex stack and STO/RCL operations are supported, e.g. there is a complex lastX which restores L & I to the stack. I can send the source to those interested I guess. I really should create a project on the web to host this. - Pauli ▼ Jeff O. Unregistered Posts: 875 Threads: 37 Joined: Jul 2005 10-09-2009, 08:20 AM Thanks for the update. It sounds pretty awesome. Walter B Unregistered Posts: 4,587 Threads: 105 Joined: Jul 2005 10-08-2009, 07:53 PM 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. ▼ Jeff O. Unregistered Posts: 875 Threads: 37 Joined: Jul 2005 10-09-2009, 08:11 AM 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: ▼ Walter B Unregistered Posts: 4,587 Threads: 105 Joined: Jul 2005 10-09-2009, 09:31 AM 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 ▼ Jeff O. Unregistered Posts: 875 Threads: 37 Joined: Jul 2005 10-09-2009, 10:18 AM Walter, I was just able to upload a 123 kB file. But this may not be the best place to host your manual. Jeff Karl Schneider Unregistered Posts: 1,792 Threads: 62 Joined: Jan 2005 10-09-2009, 01:46 AM 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. ▼ Gerson W. Barbosa Unregistered Posts: 2,761 Threads: 100 Joined: Jul 2005 10-09-2009, 05:25 PM 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.

 Possibly Related Threads… Thread Author Replies Views Last Post How much accuracy does one actually need? Matt Agajanian 23 5,772 08-26-2013, 12:46 PM Last Post: Kimberly Thompson Estimating accuracy in finite precision computations mpi 17 4,367 02-22-2013, 09:44 AM Last Post: mpi WP 34S accuracy is excellent Jeff Johnson 15 4,277 06-01-2012, 10:41 PM Last Post: Valentin Albillo 50G precision & accuracy Matt Agajanian 11 3,049 05-17-2012, 11:15 AM Last Post: Crawl Accuracy of Woodstocks Matt Agajanian 7 2,129 03-25-2012, 06:54 PM Last Post: Eric Smith HP-35 Accuracy Threshhold Matt Agajanian 0 835 03-22-2012, 09:56 PM Last Post: Matt Agajanian accuracy of integration and solve routines HP 15C LE Jan 3 1,405 02-02-2012, 01:03 PM Last Post: Marcus von Cube, Germany After the 15c LE, better chance of a basic RPN calc from HP now? nick lidakis 80 15,550 09-18-2011, 08:15 AM Last Post: snaggs Would you take a chance on this auction? Michael de Estrada 10 2,712 06-23-2011, 10:23 PM Last Post: Michael de Estrada Machine accuracy behaviour of the hp-35s and other models Mohammed Hadi 42 9,927 11-30-2009, 05:00 AM Last Post: Herbert Crepaz (UK)

Forum Jump: