▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
I have just posted the final version of the Trigonometric Functions Program (The 239 Steps :) for the 12C Platinum in the Articles Forum:
Fast and Accurate Trigonometric Functions on the HP12C Platinum
Because at least 11 significant digits are always correct all through the ranges below (I haven't found less accurate results so far  perhaps I haven't searched long enough...) , the results match those displayed by the 11C and the 15C. If fact, thanks to the 12C Platinum internal precision, is seems we have now the most accurate 10Cseries calculator regarding trigonometric functions (Hey, it has just passed Voidware's Trig Torture Test! Not bad: relative error 1.72x10^5, slightly better than the HP32SII and the HP48G (2.26x10^5)  This does not mean it's better than the HP48G, although it might be better than the HP15C: relative error 1.33x10^3).
Input ranges
SIN, COS, TAN: x <= 1E11
ASIN, ACOS: x <= 1
ATAN: x <= 9.99999999E49
Running Times
SIN, COS: 2.4 s (x <= 180)
TAN: 4.7 s (x <= 180)
ASIN, ACOS, ATAN: 2.5 s
Feedbacks appreciated.
Best regards,
Gerson.
▼
Posts: 2,247
Threads: 200
Joined: Jun 2005
Gerson,
Cool and thorough update. Thanks for the labor of love and the enthusiasm to share it with us. You make the HP12CP kick "assests"
Namir
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Thanks Namir,
I thought of including a radians mode but I quit because this would sacrifice the speed even more. Besides, a kind of annunciator would be needed. About speed, assuming that 2 is stored in register 6, 047 might be a shortcut to sine, about only 1.6 seconds instead of the usual 2.4 or 2.5 seconds (But then g GTO 047 R/S would take more time than simply R/S :)
Regards,
Gerson.
Posts: 2,309
Threads: 116
Joined: Jun 2005
Speaking of "torture tests", does anyone have such a test (or just a good collection of test cases) for the TVM functions?
Posts: 1,368
Threads: 212
Joined: Dec 2006
Quote:
Because at least 11 significant digits are always correct all through the ranges below....
Maybe this is a tangent I should take into a new thread, but the above comment fascinated me.
I am a rank amateur at all this, I must admit, but I am aware that many if not most of the "newer" HPs (i.e. those marketed after 1980) maintain at least 2 or 3 guard digits of internal precisionso the HP41 series and 15C compute internally to 13 digits, and the 42s to 15 digits, for example.
Gerson's comment seems to imply that the internal precision can be accessible to the RPN programmer. Round off error is the bane of my existence in my programs, so I would be keen to learn how to code in such a way so as to capitalize on the internal precision of these calculators. For example, is register arithmetic performed at full internal precision? At what stage is the full internal precision lost in intermediate calculations? What techniques, either in RPN programs or in direct key entry, can one use to minimize this rounding before it is desired in the final result?
Maybe I am asking a basic question intrinsically obvious to most, but I really have no clue, and this is something I would like to learn about.
Les
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Hello Les,
You're right about the gard digits on "newer" HP calculators. Thanks to them, the 10 significant figures in all my examples are correct on the HP15C, and all 12 significant figures are correct on the HP50G. However, on those calculators the gard digits are not normally available to the user. If you try this on the HP15C:
3 1/x 10000 x FRAC
and you'll get
0.333333
On the other hand, on the 12C Platinum you would get
0.33333333
By what I've read, on the 48 and 49 series 15 significant digits are accessible through SystemRPL.
Regards,
Gerson.
▼
Posts: 1,368
Threads: 212
Joined: Dec 2006
I see!
On the 12Cp, the operation of moving the decimal point permits the user access to two extra SDs, whereas they are not available on the 15C, or the 41 series, or, for that matter on the 42S (where your test gives 0.33333333).
Quote:
Thanks to them, the 10 significant figures in all my examples are correct on the HP15C....
I think you mean the 12Cp here, not the 15C? Typo?
Best,
Les
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Quote:
I think you mean the 12Cp here, not the 15C? Typo?
I did mean the 15C. I intended to say the 15C, despite being a 10digit calculator, have trigonometric functions accurate to 10 places because of the extra guard digits. That would not be possible, no matter how good the algorithm was, if it performed internal calculations with only 10 digits. On the 12CP, thanks to the two hidden digits, results accurate to 10 places were possible.
Best regards,
Gerson.
Posts: 1,368
Threads: 212
Joined: Dec 2006
This is really impressive. I have been germinating an interest in polynomial and rational approximation. I recently successfully ported the Numerical Recipes rational approximation routine in section 5.13 of the book to Maple. Couldn't get the code to work in C, but the Maple version works beautifully, and if anyone here uses Maple I would love to share it. That routine, for folks who know the work, purports to be at best a "sloppy" approximation that uses an iterative weighted leastsquares approach to roughly approach a minimax fit without going thru the the Remez rigamarole. I find the approach works very well with the trigonometric functions, and if it doesn't give a true minimax fit it comes close in these cases. Indeed I was able to generate coefficients pretty close to yours for the sine fit. Your range reduction is inspired, and indeed it helps you achieve such high accuracy with a relatively small polynomial. I am also impressed with how you experimented with the coeffiecients, truncating them to strike a balance between lower memory usage and acceptable precision.
In my experimenting I came across an example that should warm the cockles of your heart. (What is a cockle anyway?)
Try your routine to compute sin(32.888 deg). The displayed answer is 0.542998588, and when you multiply by 1000 and take the fractional part you see the full twelve digit result is 0.542998588466. This is what I see on my HP48G, HP49G+, and HP42S.
In Maple, sin(32.888*Pi/180) gives, to 25 digits, .542998588465592253694888.
But on my 15C, 41CV, and 41CX, I get 0.542998589, though when multiplying thru by 10 to see the tenth digit it is indeed a 5, the effect of the 6 rounding up the 4. When it is off the display that five rounds up the 8 to 9. But the 12Cp displays what we know to be the more correct 9 digit answer, given what we know the next three digits to be. I think that is pretty impressive.
Thanks for sharing this excellent work with us.
Les
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Quote:
I am also impressed with how you experimented with the coeffiecients, truncating them to strike a balance between lower memory usage and acceptable precision.
I just used spreadsheets, computing sines from 1 to 90 degrees and arctangents from 0 to 0.28 in steps of 0.01, graphing the functions and comparing the differences in relation to the real functions. It was just a matter of changing the coefficients and observing the maximum error and the graphs. I thought it was important to keep the maximum positive errors close to the maximum negative errors, so that they cancelled each other in random sequence of calculations. Spreadsheets were not available to people who implemented these functions through polynomial approximations on some mid 70's calculators, which makes their work even more remarkable (please see a short comment about Elektronika C315 on this old thread, under Additional information: http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/forum.cgi?read=97113#97113
Quote:
an example that should warm the cockles of your heart. (What is a cockle anyway?)

cockle1 [kók’l] noun (plural cockled)
1. mollusc with heartshaped shell: a small mollusc that has a rounded or heartshaped ridged shell in two parts.
Family: Cardiidae
warm the cockles of your heart
to give you a feeling of wellbeing or sentimental contentment
Encarta® World English Dictionary © & (P) 1999, 2000 Microsoft Corporation. All rights reserved. Developed for
Microsoft by Bloomsbury Publishing Plc.

Thanks for the opportuny of learning a new word and a new idiom :)
Quote:
But the 12Cp displays what we know to be the more correct 9 digit answer, given what we know the next three digits to be.
That's right! I had already come across a similar example when comparing the results with the 15C (a difference of one unit in the least significant digit). But then I checked the result on the 42S. Thanks for your keen remark. I forgot to mention all HP50G results in my comparison tables are accurate to 12 digits (I checked them upon my own RPN calculator written in Delphi, which displays 15 digits, 0.542998588465592 in your example).
As I said, the results are far better than I expected. When I wrote the first version of this program I didn't have a 12C Platinum for tests (I actually used an equivalent 15C program):
http://www.geocities.com/gwbarbosa/prgms_1.html
Best regards,
Gerson.
▼
Posts: 1,368
Threads: 212
Joined: Dec 2006
Quote:
I just used spreadsheets
May I ask which one? I ask since MS Excel is not really very robust for high precision calculation of math functions. It offers pretty mediocre performance for special functions and statistical distributions, but maybe it is a bit better for the trig functions. At any rate, I understand there are interfaces to import tables of values from trusted sources like Mathematica.
Quote:
I thought it was important to keep the maximum positive errors close to the maximum negative errors
You no doubt discovered that the absolute error of the final function reveals a magnification in error as the argument increases. I take it you got an equal ripple minimax fit of sin(sqrt(y))/sqrt(y) on the interval 0..(Pi/6)^2, then substituted y = x^2 to get sin(x)/x = a polynomial in x^2 + error. Multiplying thru by x will magnify the absolute error on the interval as x gets bigger. Fortunately, with range reduction you kept the interval of interest small enough this poses no hardship.
Quote:
I checked them upon my own RPN calculator written in Delphi
This is an offtopic diversion, but I have noticed that Delphi is surprisingly good for math programming. The extended data type seems to yield 17 digits of accuracy and up without much fuss, whereas the long double type in C is all over the place depending on the platform and compiler. Right now I am fooling around a bit with the 384 bit qfloat type under lccwin32. Very gratifying to get 100digit precision with so little fuss, though portability is a huge issue.
Les
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Posts: 305
Threads: 17
Joined: Jun 2007
Les, if you haven't already done so, you should read this:
http://docspdf.sun.com/8007895/8007895.pdf
Posts: 80
Threads: 11
Joined: Jan 1970
Valentin Albillo's "Tried and Tricky Trigonometrics" article in Datafile V21N1 describes a program to compute sine, cosine tangent, arc sine, arc cosine and arc tangent  to full accuracy  that fits within the 99 steps available on a standard 12C.
You can download a copy from Valentin's web pages. Alternatively the full Datafile issue is available to buy on cdrom from Jake Schwartz.
