Accuracy by chance  Printable Version + HP Forums (https://archived.hpcalc.org/museumforum) + Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum1.html) + Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum2.html) + Thread: Accuracy by chance (/thread157434.html) 
Accuracy by chance  Javier Goizueta  10072009 Recently, while testing various implementations of arbitraryprecision 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 HP35s trigonometry (leaving apart its known bugs!) so I took a look at it.
The result of the 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 12digit 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.74549998555E2, which has accumulated some roundoff error deviating
The ATAN of the 12digits argument is 0.9999962727435345... which is correctly rounded by Saturn calcs to 0.999996272744,
Note that the forensics test is a great easy way of identifying families of calculators, and was never intended to
In general, we should be aware of the randomnes in the results of tests that accumulate rounding error
Take for example the Gruenberger test that I applied to the SmartCalc 300S in this thread
Well, after all, the Saturn models' accuracy remains unsurpassed! ... and the 35s trigonometry is not only buggy, but notsoaccurate as well.
Re: Accuracy by chance  Gerson W. Barbosa  10072009
Quote:
You're right, but rather than microprocessors better algorithms have played an import role to achieve that accuracy. I think you are aware of
The HP33C and the HP34C 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)))))):
Re: Accuracy by chance  Paul Dale  10072009 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 chance  Gerson W. Barbosa  10072009
Quote: Way to go! That's exactly what I get on the 200LX:
1.564344650402309e1 A 20b with your firmware should be fantastic. I only hope the keys are good enough. Gerson.
Re: Accuracy by chance  Walter B  10072009
Quote:Well, we try our very best. Though tactile response is given by the 20b as is. Re: Accuracy by chance  Jeff O.  10082009 Quote: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 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 chance  Paul Dale  10082009 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:
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 χ2distributions 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;
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.
Re: Accuracy by chance  Walter B  10082009 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 chance  Karl Schneider  10092009 Hi, Gerson 
Quote:
Almost, but with at least one exception: Trigonometrics with smallmagnitude results that reside within the guard digits. The HP34C  and every other subsequent scientific model (HP41C/CV/CX, HP10C, HP11C, HP15C) until the Saturn processor  will return sin (3.141592653 rad) = 5.9E10, instead of 5.897932385E10. My explanation for this result is this excerpt from the following thread: http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv017.cgi?read=123880#123880
HP calculators with preSaturn microprocessors (e.g., HP15C) and many modern calculators from other manufacturers (e.g, TI82) 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
On any Pioneerseries model and some descendants, you get 9.79323846264e12 as the result. On some newer 12digit nonHP's, you might get 9.8e12 as the result.
Quote: 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 transcedentalmath errors of the HP33s and HP35s have been corrected  except perhaps for the trig error discussed in the linked thread, which was corrected for the HP20b. As for giving highlyaccurate 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 chance  Jeff O.  10092009 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 chance  Jeff O.  10092009 Thanks for the update. It sounds pretty awesome.
Re: Accuracy by chance  Walter B  10092009 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 chance  Jeff O.  10092009 Walter,
Jeff
Re: Accuracy by chance  Gerson W. Barbosa  10092009 Hello Karl,
Quote: Yes, almost is the word that was missing in my statement. Thanks for the correction! (an 's' was also missing :)
Quote: 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: I assume by highlyaccurate 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.
