▼
Posts: 25
Threads: 9
Joined: Aug 2007
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
forensic test for the HP35s (a 12 digit calculator without hidden precision) is 8.99999986001 (1.56E6 percent error)
while the HP Saturnbased 12 digits calculators (HP71B, 28*, 48*, 42s, etc.) give 8.99999864267 (1.51E5 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 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
from the perfect 1.74549998554886...E2 result (computed with unlimited precision).
The ATAN of the 12digits argument is 0.9999962727435345... which is correctly rounded by Saturn calcs to 0.999996272744,
while the 35s gives the notsocorrect 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 14digit 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 notsoaccurate as well.
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Quote: Well, after all, the Saturn models' accuracy remains unsurpassed! ... and the 35s trigonometry is not only buggy, but notsoaccurate 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 ndigit result."
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)))))):
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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
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.564344650402309e1
0.999996272742885
1.745499985548866e2
0.999996272742885
1.56434465040737e1
9.000000000029361
A 20b with your firmware should be fantastic. I only hope the keys are good enough.
Gerson.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
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.
Posts: 875
Threads: 37
Joined: Jul 2005
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 HP34c 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 HP16c 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:
Source
Walter's documentation
Any updates on the above or other details regarding your project?
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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).
 HP41 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 χ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;
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
▼
Posts: 875
Threads: 37
Joined: Jul 2005
Thanks for the update. It sounds pretty awesome.
Posts: 4,587
Threads: 105
Joined: Jul 2005
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.
▼
Posts: 875
Threads: 37
Joined: Jul 2005
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:
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
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
▼
Posts: 875
Threads: 37
Joined: Jul 2005
Walter,
I was just able to upload a 123 kB file. But this may not be the best place to host your manual.
Jeff
Posts: 1,792
Threads: 62
Joined: Jan 2005
Hi, Gerson 
Quote:
The HP33C and the HP34C 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 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
\ /
sin 3.14159265358000
= 0.00000000000979323846264
 
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:
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 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.
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Hello Karl,
Quote:
Quote:
The HP33C and the HP34C 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 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.
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 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.
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 highlyaccurate forensic results, it's impossible without carrying many extra digits of precision in the calculations  three is not enough.
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.
