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.
