A closer look at the 35s bug list Message #49 Posted by Dieter on 4 Sept 2011, 12:34 p.m., in response to message #48 by Paul Dale
A few remarks regarding the 35s bug list.
First, I would not consider the fact that ALL mode often requires scrolling a bug. It's intended this way, simply because ALL does what it says: it displays *all* digits of the mantissa. Due to the limited space (14 displayable digits) this cannot be done including the exponent. Yes, that's certainly not nice (and I really appreciate the 34s ALL nn mode), but it's the way the 35s is supposed to work. This feature should be moved to the section of "items that cannot be classified as bugs since they are documented or work correctly", which is where it belongs.
Then there is the cos/tan issue (bugs 2 and 3) for angles close to 90 degrees.
Let's take a closer look at this.
correct mantissa HP35s error

cos(89,9) 1,74 532 836 590 1,74 532 836 590 0
cos(89,99) 1,74 532 924 313 1,74 532 924 306 7D 12
cos(89,999) 1,74 532 925 191 1,74 532 925 091 1D 10
cos(89,9999) 1,74 532 925 199 1,74 532 925 2D 10
cos(89,99999) 1,74 532 925 199 1,74 532 92 5D 9
cos(89,999999) 1,74 532 925 199 1,74 532 9 3D 8
cos(89,9999999) 1,74 532 925 199 1,74 532 9D 7
cos(89,99999999) 1,74 532 925 199 1,74 532 925 199 0
cos(89,999999999) 1,74 532 925 199 1,74 532 925 199 0
cos(89,9999999999) 1,74 532 925 199 1,74 532 925 199 0
The problem seems to be the loss of digits as the argument moves closer to 90 degrees.
So, instead of full 12 digit precision the result may carry only 11 to 6 valid digits. The remaining digits are simply missing. Yes, precision is lost. But are these results completety "dud", as the bug list calls it? All results are correct within 1 ULP of the displayed result.
By the way, I now remember a discussion on the 34s quantile functions, proposing to return a result with less than the full 16 digits, say: 10 or 8, if a full precision result would take too much time or effort. ;)
The loss of precision in the cosine routine also affects the tanresults that are obviously evaluated by dividing sine by cosine:
correct mantissa HP35s error

tan(89,9) 5,72 957 213 354 5,72 957 213 355 +1D 12
tan(89,99) 5,72 957 789 313 5,72 957 789 338 +2D 11
tan(89,999) 5,72 957 795 072 5,72 957 795 401 +3D 10
tan(89,9999) 5,72 957 795 130 5,72 957 795 785 +6D 10
tan(89,99999) 5,72 957 795 131 5,72 957 812 200 +2D 8
tan(89,999999) 5,72 957 795 131 5,72 957 877 856 +8D 7
tan(89,9999999) 5,72 957 795 131 5,72 960 832 397 +3D 6
tan(89,99999999) 5,72 957 795 131 5,72 957 795 131 0
tan(89,999999999) 5,72 957 795 131 5,72 957 795 131 0
tan(89,9999999999) 5,72 957 795 131 5,72 957 795 131 0
These tanresults returned by the 35s can easily be obtained by manually dividing the sine values by the cosine as shown above.
Example:
tan(89,999)
= sin(89,999) / cos(89,999)
= 0,999999999848 / 1,74532925091 E5
= 5,72 957 795 400 E+4
tan(89,99999)
= sin(89,99999) / cos(89,99999)
= 1,00000000000 / 1,745329 E7
= 5,72 957 877 856 E+6
tan(89,9999999)
= sin(89,9999999) / cos(89,9999999)
= 1,00000000000 / 1,74532 E9
= 5,72 960 832 397 E+8
As you see, we get exactly the same results as returned by the 35s. In fact, the 35s may even be slightly better due to the internal 15digit arithmetics.
So, the loss of precision in the tangent calculation simply is a result of the digit loss in the cosine routine.
There are other examples of earlier HP calculators showing loss of precision in their trig functions. Take a look at the HP41 (and most probably the HP67/97 and 15C as well) in radians mode and see how the results of the good old times compare to today's:
mantissa as returned by correct result
"good old HP" HP35s

sin(3,1415) 9,26 535 898 7 9,26 535 896 582 9,26 535 896 607
sin(3,14159) 2,65 359 2,65 358 979 2,65 358 979 324
sin(3,1415926) 5,35 9 5,35 897 9 5,35 897 932 385
sin(3,14159265) 3,59 3,58 979 3,58 979 323 846
sin(3,141592653) 5,9 5,89 793 238 463 5,89 793 238 463
sin(3,141592654) 4,1 4,10 206 761 537 4,10 206 761 537
Should we also consider the 41/67/97/15C result in the left column to be "dud"? Is this also known as a bug in these calculators, returning "dud" sine results for arguments close to Pi? It's the same as with the 35s: in sin(3,1415) the last two digits are wrong, and as the argument gets closer to Pi, precision drops to merely two valid digits. As opposed to the 35s who returns at least six. ;)
So, let's be fair.
Dieter
