▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Hello,
I have a trigonometric functions program that should work on the newer Platinum. However, it remains untested because I don't intend to get a Platinum just because of this, at least for the time being.
The accuracy is comparable to that of the HP35, I'd say it's even slightly better, and I don't mean the buggy one :)
I estimate running times to be around 2 seconds for SIN and COS (twice as much for TAN as it is calculated as SIN/COS for the sake of accuracy); and under 3 seconds for ASIN, ACOS and ATAN. It is not as fast as it could be because the constants used by the program are all builtin rather than previously stored in the registers.
Keying in a 274step untested program is not exactly what one would choose for the weekend, but in case someone wants to try, here it is:
Trigonometric Functions on the HP12C Platinum (newer one only!)
In an effort to make the task less boring, I have used Luiz's keyset4 font (thanks, Luiz!) in the listings, as you can see.
I have doublechecked the listing and I have also provided a working equivalent program for the HP15C.
Thanks,
Gerson.
Edited: 4 Feb 2006, 7:28 p.m.
▼
Posts: 4,027
Threads: 172
Joined: Aug 2005
Hi, Gerson;
first of all, shame on me... (you know why, don't you?)
Second, thanks for using the fonts. I'm suspect to say, but the listing looks good, don't you agree?
I tested the program with the simplest values: 45 SIN > .7071067812 ([STO] 9 for testing)
45 COS > same as above
[x^2] [RCL]9 [x^2] [+] [f][PREFIX] > .999999999
45 TAN > 1.000000000
The complementary values were obtained with the value stored in R9.
In time: a few glitches in your listing (just little peebles...). [squareroot] and [GTO] are prefixed functions in the HP12C (they are not in the HP15C, where you wrote the routines, right?) and step #029 is repeated twice in the sequence.
I see it is a .GIF, and you'd have to do it all again. If you actually are going to update it, consider an initial remark with the changes, only.
Congrats! Great program!
Luiz (Brazil)
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Hi Luiz,
Thank you very much for taking the time to test it. I really didn't expect a so prompt response!
Sorry for having forgotten the prefix keys. I will revise it later, just o matter of editting the text and converting it to .GIF.
About the test, 45 SIN > .7071067812 is better than .7071067813 on the 15C. But I didn't like the '.999999999'. On the 15, this would result '1.000000000'. A '9' is missing, isn't it?
I didn't use fullaccuracy coefficients in the minimax polynomial for sine , to save some steps:
3,2818376137E08
5,5539160587E14
4,4756602223E20
2,0935117545E26
(max abs error: 8,02E14)
Instead, I used:
3,28183759E08
5,5539E14
4,47304E20
2E26
(max abs error: 1,87E11)
This should have been good enough. Have you seen the comparison table with the 15C and 35? If the displayed result is correct to 10 digits, this should be nice for a financial calculator, it's most of the time set to FIX 2 anyway :)
Cheers,
Gerson.
PS.:
1) Would you try this:
asin(acos(atan(tan(cos(sen(9))))))
9 R/S GTO 094 R/S GTO 104 R/S GTO 157 R/S GTO 141 R/S GTO 123 R/S
On the 15C the result is 9.000878935
2) The X register is always preserved
3) How about the running time?
Thanks.
Edited: 4 Feb 2006, 9:39 p.m.
▼
Posts: 4,027
Threads: 172
Joined: Aug 2005
Hey, Gerson; my pleasure.
Quote: About the test, 45 SIN > .7071067812 is better than .7071067813 on the 15C. But I didn't like the '.999999999'. On the 15, this would result '1.000000000'. A '9' is missing, isn't it?
You're right. I did not count the '9's, just keyed them in... Sorry! And as you see the last digit, the '2' (12Cp) instead of '3' (15C) leads to a lower result. Quote: 1) Would you try this:
asin(acos(atan(tan(cos(sen(9))))))
9 R/S GTO 094 R/S GTO 104 R/S GTO 157 R/S GTO 141 R/S GTO 123 R/S
Resulting value is 9.000148569. Closer to the original value. The HP12Cp works with more internal digits... I still believe this is the main cause for the lowvalue IRR issue in the first Platinum units. And the program runs fast in the HP12Cp. In time: I used a newer model as specified, with parenthesis and backspace/undo features. I think of keying it in one of the earlier units and test it, too. I'll let you know.
Cheers.
Luiz
▼
Posts: 4,027
Threads: 172
Joined: Aug 2005
Hi Gerson, all;
in my previous post, I wrote that the asin(acos(atan(tan(cos(sen(9)))))) resulted in 9.000148569. With this result in the display, I keyed in: 9 [] and I got the following mantissa: 1485693900 I'm not sure: should the two additional significant digits '3' and '9' be there?
Luiz (Brazil)
Edited: 4 Feb 2006, 10:04 p.m.
▼
Posts: 93
Threads: 2
Joined: Jul 2005
Congrats Luiz, you found the 2 hidden digits :)
3 [1/x] 1000 [x] [g][FRAC] also shows 0.333333333.
On the old 12cp and HP12C we see 0.333333300.
So the new 12cp should perhaps be called the 12d, as it has 12 digits under the hood :)
Best Regards,
Tony
Posts: 4,027
Threads: 172
Joined: Aug 2005
Hi, guys;
I must confess I've been a bit selective in therms of what to read, mainly because of a lack of time and sometimes because of the huge amount of threads/info that can be found here. My bad...
I remember reading about the (old...) TI58/59 hidden digits that can be shown under certain circumstances, and I also tested a few keystroke sequences to see the HP30S hidden digits as well. I also remember reading about the HP12Cp internal precision due to the specific processor. I know that higher internal precision allows better final resulting values, and it is not necessarily kept in the final result/display.
I was completely unaware of the fact that the newer HP12Cp could handle results with a 12digit mantissa. This is actually a new design. Not sure if these digits were suppressed in the earlier, bugfilled series or if they are actually added to the new design.
Thanks, guys, for any new data. Also, forgive me if this is a knwon fact and I treated it as new, I'm sort of enthusiastic with unknown facts. If so, can you point me any thread or article that mentions this fact?
Thanks again.
Luiz (Brazil)
Edited: 5 Feb 2006, 10:44 p.m.
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Hi Luiz,
Quote:
can you point me any thread or article that mentions this fact?
Yes, Tony told me about these two hidden digits almost three months ago:
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv015.cgi?read=81563#81563
By the way, I have updated the listing to include the prefix keys I had missed. Thanks for having warned me about this. Also, line 147 has been changed from g x^{2} to g LSTx. This is more effective and doesn't cause a needless decrease in the ACOS accuracy, at least on the 15C. The forensic result (see below) in now 9.000270299. On the Platinum, due to the extra digits, the difference will be less noticeable, if any.
Cheers,
Gerson.
Posts: 2,761
Threads: 100
Joined: Jul 2005
Hi Luiz,
Thanks again.
9.000148569 is a good result, the HP15C and HP41 internal functions return 9.000417403. See Mike Sebastien's Calculator Forensics Project. I think it is still possible to adjust the constants to take advantage of the Platinum's features, but I am pleased with the result.
When you subtract 9 from the result the two addition digits come from the extra internal digits in the Platinum.
I don't think the program will work on the older unit because there's a limitation in the number of steps it can handle, just 255 if I am not wrong.
One more question: you said the program ran fast. Is it possible to know exactly how fast? Would you please time 45 TAN? In the 15C version, it takes about 16 seconds! As I said, the program might run even faster if there was a separate initialization routine that stored all the constants in the registers, but then we'd have to run it every time we were not sure about the registers contents. As I know the Platinum is fast, I chose this approach for ease of use.
Cheers,
Gerson.

Update: Thanks to a minor change (see above), the forensic result in the 15C version of the program is now 9.000270299. We should notice the forensic result alone is not a good indicator of the overall accuracy, since the 15C internal function, which are far better, return a worst result: 9.000417403.

Edited: 6 Feb 2006, 7:13 a.m.
