Hi, all:

Though this is essentially a commentary to a posting by Ralph, I'm starting a new thread as my commentary isn't directly related to the original thread, "Some 49G+ Limitations".

Ralph posted:

"c)asin(acos(atan(tan(cos(sin(7))))))
[...]
HP41CX(6.999519575) worse than HP49G+, HP48G

Lest people would think that the HP-41CX has serious accuracy problems with this particular computation, let's make clear that this lack of accuracy stems from the fact that this example is very ill-conditioned, as the cosine function is being evaluated for a very small argument, where serious cancellation is taking place. Let's see:

• The Cosine function, COS, is being applied to an argument which itself is a sine function, which will return a value in the range [0-1]. Thus COS' argument will be 1 at most (in this particular example, it is SIN(7º) ).

• Further, though not stated by Ralph, all trigonometric functions are being calculated in Degrees, not Radians.

• This means that we're computing the Cosine of a very small angle, between 0º and 1º, namely SIN(7º) in this particular example which is 0.1218+, so we're in fact computing COS(0.1218º), a truly small angle indeed, which, to add insult to injury, is equivalent to 0.00213+ radians, i.e., a really, really small argument.

• And, regrettably, this petite argument causes a large loss of accuracy, because for very small arguments, in radians, we have:
  

        COS(X) = approx. equal to 1 - X^2/2
  
  

  and as X is very small to begin with, half its square is much smaller (0.000002262109806), which, when subtracted from 1, effectively loses half its significant digits, giving 0.9999977379.
  

You can see the loss easily, just subtract this result from 1 again, to get 0.0000022621, which is missing its last 5 digits of accuracy (namely ...09806). So, it's no wonder the HP-41CX gives such a seemingly "inaccurate" final result. The loss would be even greater if still smaller arguments were tested, for instance let's try 1 instead of 7:

  asin(acos(atan(tan(cos(sin(1)))))) = 0.9990167403

   XEQ RAD

   asin(acos(atan(tan(cos(sin(1)))))) = 1.000000000   

   XEQ DEG

   acos(asin(atan(tan(sin(cos(7)))))) -> 6.999999972

I hope this helps to understand what's happening and why a seemingly poor performance while doing the original test doesn't necessarily mean same poor overall performance, far from it. The original test is a contrived, ill-conditioned case, not to be regarded as a valid measure of general accuracy for the model tested.

Best regards from V.

Edited: 11 Feb 2005, 10:22 a.m.

Interestingly, the HP-30S gives the answer of 7.000000000
to the problem. I believe it uses many more internal digits in calculation.

I have tried various Sharp, TI, and HP calculators on this
example. I know that the TI-30XII, HP-41, HP-6S, HP-39, and
HP HP-48X do not give exactly 7 as does the HP-30S.

1234 to remove

Valentin,

Excellent short, clear and concise discussion. Thanks!

regards,

Bill

I agree it's not a good test for accuracy, but it is a good test to distinguish the internals of one calculator from another or at least the algorithms used. The same test (with 9 instead of 7) is used here: http://www.rskey.org/~mwsebastian/miscprj/forensics.htm as a means to identify which chip is used in a scientific calculator.

Edited: 12 Feb 2005, 6:05 p.m.

Thanks for demonstrating this again. It's easy for idealistic students and math enthusiasts to fault a calculator in this way when the same properties make it impossible to keep such tight tolerances on an actual machine or circuit you might try to design to work along the same lines as the posted equation. The inaccuracies in manufacturing or measurement, plus the effects of varying operating temperatures, etc., become hopeless before the calculator's inaccuracy does. IOW, the "problem" becomes irrelevant, and ten digits is far more than most real-life situations need.

i have a slightly different take on this problem. i can excuse the 41c but not the 49g+. a top of the range, 21st century calculator should not be caught out by this problem. either it should have more internal precision (like the 30s & 9g) or some form of dynamic precision.

Hi,

Valentino, thanks for the explanations made over this problem.

Now, although this thread is not directly connected to the one it makes reference, I hope that from what I posted on that other thread, people wouldn't think that the HP41CX has serious accuracy problems, nor indeed that that problem was exposed as a measure of general accuracy for this calculator (I myself have a 41CX which is the one I'm most fond of). We where discussing instead about the HP49G+ and how it handled precisely this extreme or ill-conditioned situation as a means of what Hugh Steers has posted here. In fact, on my response there, I tried to give HP calculators a chance by exposing how the different models have been improving the accuracy of these extreme results through the years, focussing mainly on the internal technology development.

Ralph