asin(acos(atan(tan(cos(sin(7))))))



#2

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
which loses 7 digits of accuracy instead of 5-6 in the original example. Now, just to further see that the problem has nothing to do with the HP-41CX's internal algorithms, let's evaluate this second, worse example, but this time in RADians instead of DEGrees:
   XEQ RAD

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

which gives a perfect result back and clearly shows the true accuracy, once we're no longer dealing with an ill-conditioned problem. Another revealing test, this time in the original DEGrees setting, is to exchange the order of evaluation of SIN and COS (and also that of ACOS and ASIN as well):
   XEQ DEG

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

and you can see that we have a decent result, with a mere loss of slightly over one significant digit, because this time the argument for COS is 7º, instead of 0.1218º, i.e., almost 60 times greater.

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.


#3

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

#4

Valentin,

Excellent short, clear and concise discussion. Thanks!

regards,

Bill

#5

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.

#6

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.

#7

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.

#8

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


Possibly Related Threads...
Thread Author Replies Views Last Post
  [HP-PRIME kernel] asin, ASIN, aSin ??? CompSystems 1 329 11-03-2013, 07:29 AM
Last Post: Han
  HP-35s Cos[x] and Tan[x] bugs resolved? Thomas Windisch 2 480 10-31-2013, 01:12 PM
Last Post: Dieter
  HP 15C LE COS key troy 6 597 09-18-2011, 12:05 PM
Last Post: From Hong Kong
  where is 35s cos bug Andrew Nikitin 3 406 10-06-2008, 01:41 AM
Last Post: Karl Schneider
  [OT] (Cos x)^x Chuck 11 913 12-01-2007, 01:48 PM
Last Post: Karl Schneider
  alternative cos(x) and tan(x) [HP-33S] Gerson W. Barbosa 7 575 07-27-2007, 02:22 PM
Last Post: Gerson W. Barbosa
  The arc tan flaw in early HP35 ROM is elucidated Jacques Laporte 2 320 04-10-2006, 08:39 AM
Last Post: Jacques Laporte
  What is the ans. of sin(32 pi) in rad mode cre 13 937 12-10-2005, 06:38 PM
Last Post: John Smitherman
  incorrect integral of 1/(sin x) J.C.Boco 9 720 11-20-2005, 02:09 AM
Last Post: Karl Schneider
  Sin(Pi) in Radians Mike 33 2,181 08-29-2004, 02:58 PM
Last Post: Eddie Shore

Forum Jump: