Accuracy by chance



#15

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.


#16

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


#17

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


#18

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.


#19

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.
#20

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:

Source

Walter's documentation

Any updates on the above or other details regarding your project?


#21

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


#22

Thanks for the update. It sounds pretty awesome.

#23

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.


#24

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:


#25

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


#26

Walter,

I was just able to upload a 123 kB file. But this may not be the best place to host your manual.

Jeff

#27

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:

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv017.cgi?read=123880#123880


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.


#28

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,988 08-26-2013, 12:46 PM
Last Post: Kimberly Thompson
  Estimating accuracy in finite precision computations mpi 17 4,462 02-22-2013, 09:44 AM
Last Post: mpi
  WP 34S accuracy is excellent Jeff Johnson 15 4,375 06-01-2012, 10:41 PM
Last Post: Valentin Albillo
  50G precision & accuracy Matt Agajanian 11 3,145 05-17-2012, 11:15 AM
Last Post: Crawl
  Accuracy of Woodstocks Matt Agajanian 7 2,225 03-25-2012, 06:54 PM
Last Post: Eric Smith
  HP-35 Accuracy Threshhold Matt Agajanian 0 856 03-22-2012, 09:56 PM
Last Post: Matt Agajanian
  accuracy of integration and solve routines HP 15C LE Jan 3 1,434 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 16,088 09-18-2011, 08:15 AM
Last Post: snaggs
  Would you take a chance on this auction? Michael de Estrada 10 2,802 06-23-2011, 10:23 PM
Last Post: Michael de Estrada
  Machine accuracy behaviour of the hp-35s and other models Mohammed Hadi 42 10,292 11-30-2009, 05:00 AM
Last Post: Herbert Crepaz (UK)

Forum Jump: