For those of you who might be interested, an improved and revised version of Fast & Accurate Trigs on the HP-12C Platinum is available at the Articles Forum.

The following enhancements have been made:

1) The acos(x) function bug has been fixed. The function was not so accurate in the previous version for |x| >= 0.999999 (errors starting at the 7th or 8th significant figures);

2) Angular mode setting: DEGREES and RADIANS. GRAD is also possible with six keystrokes;

3) There is an optional routine for those who prefer to have the answers rounded to ten digits. This allows the forensic test to return 8.9911614, 8.99725190 and 9.000417403 when the display is set to FIX 7, 8 and 9, respectively. The latter matches exactly the HP-15C result. (No changes in the coefficients have been made);

The program is useful to check if your 12C Platinum can handle all 399 steps. The program is 276 steps long but there are 123 optional steps :-)

Thanks Tony for providing a handy formula for the acos(x) function, Rodger Rosenbaum for his recent "What should we get get?" posts and Les Wright for first calling my attention to an interesting example (sin 32.888 deg).

Gerson.

Edited: 9 Dec 2006, 8:07 p.m.

Gerson,

In your write-up, http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?read=654
you discuss the cases of SIN(32.888) and SIN(34.444).

You have a comment about the HP15C's result from SIN(34.444):

"In this case, according to its rounding method, the HP-15C should return 0.5656004784. Unless, of course, a slight error in the thirteenth significant digit has turned those '499' into '500' or higher."

The HP15C calculates internally to 13 digits, and it is almost certain that the last 3 digits were probably greater than 500, which is why if you press f CLEAR PREFIX after calculating SIN(34.444), you will see 5656004785.

Unfortunately, it's not easy to see the HP15C's internal 13 digit result, but on the Saturn calculators, the internal 15 digit result is accessible. Just such an effect is responsible for the Saturn machines' error when performing the Savage benchmark. At one point in the calculation, the calculator is called upon to compute ATN(1689.99993538). The exactly correct result is 1.57020461086499873+, but the Saturn returns a 15 digit result whose last 3 digits are slightly greater than 500. This is then rounded up instead of down, giving a result of 1.57020461087, which is one unit too large in the LSD. This is because the trailing digits ...499873+ are so close to the dividing value of ...500000 that it would be required to carry many more digits to properly distinguish the correct 12 digit rounded result. And, as they say in the HP15C Advanced Functions handbook, that would be too expensive to do.

The peculiarities you are discussing in your article are well known artifacts of sucessive roundings. I discussed this in comp.sys.hp48 about 3 years ago. One can use the dot product function (DOT) on the HP48 to explore the workings of the internal 15 digit arithmetic and the roundings to 15 and 12 digits:

Quote:

---

Consider this:
[502000000122E15 1] [1 4995] DOT -- result 5.02000000123E15
The exact result is, of course, 5020000001224999, which should round to 5.02000000122E15. I think they must be rounding the 16 digit value to 502000000122500 and then rounding up to get the final 12 digit result. They are not rounding the 16th digit to even; they are ALWAYS rounding it up. But they seem to be doing two roundings; how else to explain the result?

[502000000121E15 1] [1 4994] DOT gives 5.02000000121E15, so they are not simply looking at all digits past the 15th and then incrementing digit 15 if there is any non-zero value in the digits past 15 (sticky bit set). They are also not simply keeping the 15 form plus the sticky bit and passing that to a routine for proper rounding to even in a 12 digit result.

I chose this example just because it shows how a bad result can come from double rounding.
The exact value of the sum from my first example is 5020000001214995 -- if we round it to a 15 digit result (with rounding to even), we get 502000000121500. Now, if we round this to a 12 digit result (rounding to even), we get 502000000122 But, clearly, if we start from the 16 digit result 5020000001214995 and round in one operation to a 12 digit result (rounding to even), we should get 502000000121.

One way to solve this problem that has occurred to me is to pass a flag to the 15 digit arithmetic routines, telling them whether the result is to be later rounded to 12 digits. This way, those routines could round properly (with rounding to even) to 15 digits for use
in accumulating inner products, for example, but not rounding (and setting the sticky bit) if another routine was to round to 12 digits.

---

The evils of repeated rounding are mentioned in Knuth, "The Art of Computer Programming", Volume 2.

So, if you want a 10 digit result (or 8 or 9 digit result), always go from your most precise first result to the final rounded result in one step; don't do repeated roundings.

Quote:

---

The HP15C calculates internally to 13 digits, and it is almost certain that the last 3 digits were probably greater than 500, which is why if you press f CLEAR PREFIX after calculating SIN(34.444), you will see 5656004785.

---

That's what I had imagined. At first I thought the HP-15C results always complied to the HP rounding philosophy. Then I read in one of your recent posts "Some of the mathematical functions such as the transcendentals and trigonometrics don't always meet the goal". I was just trying to explain some differences of one unit in the LSD I had been observing. I didn't mean the program is better than the HP-15C. Similar examples may cause the program to show the same error of one unit in the LSD.