asin(acos(atan(tan(cos(sin(7)))))) « Next Oldest | Next Newest »

 ▼ Valentin Albillo Unregistered Posts: 1,755 Threads: 112 Joined: Jan 2005 02-11-2005, 10:12 AM 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. ▼ Thomas Cox Unregistered Posts: 25 Threads: 12 Joined: Nov 2008 02-11-2005, 12:31 PM 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 bill platt Unregistered Posts: 2,448 Threads: 90 Joined: Jul 2005 02-11-2005, 12:50 PM Valentin, Excellent short, clear and concise discussion. Thanks! regards, Bill Katie Unregistered Posts: 265 Threads: 29 Joined: Jan 1970 02-11-2005, 11:12 PM 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. Garth Wilson Unregistered Posts: 887 Threads: 9 Joined: Jul 2007 02-12-2005, 01:43 AM 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. hugh steers Unregistered Posts: 536 Threads: 56 Joined: Jul 2005 02-12-2005, 03:45 PM 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. Ralph Unregistered Posts: 28 Threads: 4 Joined: Jun 2007 02-14-2005, 07:04 AM 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 1,093 11-03-2013, 07:29 AM Last Post: Han HP-35s Cos[x] and Tan[x] bugs resolved? Thomas Windisch 2 1,493 10-31-2013, 01:12 PM Last Post: Dieter HP 15C LE COS key troy 6 1,717 09-18-2011, 12:05 PM Last Post: From Hong Kong where is 35s cos bug Andrew Nikitin 3 1,226 10-06-2008, 01:41 AM Last Post: Karl Schneider [OT] (Cos x)^x Chuck 11 2,757 12-01-2007, 01:48 PM Last Post: Karl Schneider alternative cos(x) and tan(x) [HP-33S] Gerson W. Barbosa 7 2,127 07-27-2007, 02:22 PM Last Post: Gerson W. Barbosa The arc tan flaw in early HP35 ROM is elucidated Jacques Laporte 2 1,046 04-10-2006, 08:39 AM Last Post: Jacques Laporte What is the ans. of sin(32 pi) in rad mode cre 13 3,009 12-10-2005, 06:38 PM Last Post: John Smitherman incorrect integral of 1/(sin x) J.C.Boco 9 2,178 11-20-2005, 02:09 AM Last Post: Karl Schneider Sin(Pi) in Radians Mike 33 6,469 08-29-2004, 02:58 PM Last Post: Eddie Shore

Forum Jump: