# HP Forums

Full Version: Inaccuracy of TAN near 75° in rad mode
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Hello,

It seems the 34s is having troubles getting the 10th digit correct when it evaluates the tangent of angles near 75 degrees in radians mode. I know this looks kinda silly but I thought it would be worth reporting.

$$TAN\left(73\frac{\pi}{180}\right) = 3.27085261848\leftarrow ...53$$

$$TAN\left(75\frac{\pi}{180}\right) = 3.73205080757\leftarrow ...48$$

$$TAN\left(77\frac{\pi}{180}\right) = 4.33147587428\leftarrow...17$$

The left arrow indicates what the last 2 digits should be.

Both sine and cosine are getting all digits right.

Thanks.

Marcio

CORRECTION: All answers given by the 34s in this thread are correct. The calculators I used to compare the results, those being the 50g, Prime and 35s, output inaccurate results for two main reasons, the first was the limited precision (12 digits) and the second was the numerical inaccuracy of tan as the angles approache 90 degrees. Read on for details!
Confirmed for 73° for 3.3 3718.

A truly amazing result for tan(73*pi/180) as the HP 95LX, 100LX & 200LX give the same wrong answer, also in the following decimal digits!

ie ...848... in fact seems correct.

WP 34S exonerated!
What is your gold standard, Marcio?
OK, have now tested 32SII, 42S, 50G - all return the 853 answer.

The 3 organizers, TI-86, voyager 200, TI-30X Pro - all say 848, which is definitely the correct answer - not to mention the correct WP 34S!
(06-30-2015 06:59 PM)Gerald H Wrote: [ -> ]OK, have now tested 32SII, 42S, 50G - all return the 853 answer.

The 3 organizers, TI-86, voyager 200, TI-30X Pro - all say 848, which is definitely the correct answer - not to mention the correct WP 34S!

How did you come to this conclusion?

Thanks
My gold standard is the HP LX organiser series - I don't believe a false result has been found & they've been around donkey's years.

If you can get one I recommend a 200LX.
Well, yes. I should have checked Wolfram Alpha before opening this thread.

tan (73)

A bit surprised both the Prime and 50g gave incorrect answers.

OK then, if it is OK with you, I am gonna ask the moderators to delete all these which have been nothing but a futile exercise.
The 853 answer is delivered only by the HP calculators using legacy software.

Have a look at how the HP models I mention cluster in this list:

http://www.rskey.org/~mwsebastian/miscprj/results.htm

as do the organisers, but in a different position.
You certainly should not have consulted Wolfram Alpha - the thread is very interesting & useful.

I congratulate you on finding this error & on making it public.

The thread is most definitely useful.
You shouldn't delete the thread - others should know Prime & 50G etc give SAME wrong answer!
(06-30-2015 07:26 PM)Gerald H Wrote: [ -> ]You shouldn't delete the thread - others should know Prime & 50G etc give SAME wrong answer!

Alright.
Also, add the 35s to that list. Interestingly enough, that program by Hosoda will also give the same incorrect answers as the 50g and the
Prime.

Thanks.

Marcio
Not only Hosoda.

There's a library for the 50G called Long Float that delivers hundreds of decimal places & makes the same error!!!

Horror!!!

Edit: But read on, Hosoda & Long Float & HP will be justified!
(06-30-2015 07:15 PM)Marcio Wrote: [ -> ]Well, yes. I should have checked Wolfram Alpha before opening this thread.

tan (73)

A bit surprised both the Prime and 50g gave incorrect answers.

My '34S (in double-precision mode) differs from Wolfram Alpha - at least on tan (73*pi/180) - only starting in the 32nd decimal place:

WP-34S:3.270852618484140865308856257305407
.... W/A: 3.2708526184841408653088562573054107771059....

Jake
My previous posting contradicts my posting #8 ("only").

Perhaps a hand calculation is the only way to settle the matter?

For me, Aribas returned 848..... so I'm pretty sure it's correct.

Maybe someone else can confirm the result?
(06-30-2015 03:18 PM)Marcio Wrote: [ -> ]It seems the 34s is having troubles getting the 10th dec number correct when it evaluates the tangent of angles near 75 degrees in radians mode. I know this looks kinda silly but I thought it would be worth reporting.

1. The 34s is fine.
A bit of simple calculus explains it all.

2. tan(75°) = 3,7320 50807 56887 72935 27446 34150 58723 ...
And that's exactly what the 34s returns.

3. 75° = 1,3089 96938 99574 71826 92768 07636 64595 ... rad
And that's exactly what the 34s returns.

However, on a simple 12-digit calculator, 75° is rounded to 1,3089 96939 00 rad. Due to roundoff in the last digit, the value in radians may be off by 5 units in the 13th digit. Since the derivative of tan x at this point is approx. 15, this translates to a potential error of 7 units in the last (12th) digit:

The exact argument (75*pi/180) is about halfway between 1,3089 96938 99 and ...900.
If it happens to get rounded down, you get tan(1,3089 96938 99) = 3,73205080748
If it happens to get (correctly) rounded up, you get tan(1,3089 96939 00) = 3,73205080763

You see that a change in 1 ULP of the argument makes the tanget change by 15 ULP (!), just as expected.
Since the argument always has a potential roundoff error of 0,5 ULP, it may and will be up to 7 ULP off.

Now try this with 89,9° and the last four (!) digits will be off.
Try 90° and the result becomes completely useless. ;-)

So the problem is the limited accuracy of the manually calculated argument. 75 degress is not exactly 1,30899693900 radians, so the tangent is inaccurate. On the other hand the 34s with its internal 39-digit precision gets it right. And so does the 35s or the 50G if you calculate tan(75°) in degrees mode: the internal calculations are done with three additional digits so the error does not show up. However, manually converting 75° to radians introduces a very slight error that is large enough to throw the tangent off in the last one or two digits. And that's exactly what you see here. The 34s returns a correct 12-digit result because even in SP mode it uses 16 digit precision and the error only affects the (not displayed) 15th digit.

Dieter
OK, thanks for the detailed explanation.

I should also point out that the problem only rises (more significantly) when the angle is between 73 and 77 degrees. There must be a reason for that.
(06-30-2015 03:18 PM)Marcio Wrote: [ -> ]CORRECTION: All answers given by the 34s in this thread are correct. The answers given by the calculatorss I used to compare the results, those being the 50g, Prime and 35s, are not!

Right, the 34s results are correct.
But the 50g and 35s are fine as well. Their results are also correct.
The error is in the argument manually calculated by the user. It is rounded to 12 digits, and so these calculators return the exact result for this rounded argument.
The 34s would show the same error, but it uses at least 16 digits of which only 12 are displayed.

Dieter
(06-30-2015 08:06 PM)Dieter Wrote: [ -> ]Right, the 34s results are correct.
But the 50g and 35s are fine as well. Their results are also correct.
The error is in the argument manually calculated by the user. It is rounded to 12 digits, and so these calculators return the exact result for this rounded argument.
The 34s would show the same error, but it uses at least 16 digits of which only 12 are displayed.

Dieter

In this particular case, the 73 degrees, say it was rounded to 9 digits instead?
(06-30-2015 07:49 PM)Marcio Wrote: [ -> ]I should also point out that the problem only rises (more significantly) when the angle is between 73 and 77 degrees. There must be a reason for that.

No, there is nothing special about 73, 75 or 77 degrees. The error gets larger as the angle approaches 90° and, here more important, if the angle in radians happens to round not very well to 12 digits.

Example:
tan 75,2° = 3,7848 48088 37
75,2° = 1,3124 87597 49973... radians, which rounds nicely to 12 or even 11 digits.
tan(1,3124 87597 50) = 3,7848 48088 37

q.e.d.

Dieter
(06-30-2015 08:11 PM)Marcio Wrote: [ -> ]In this particular case, the 73 degrees, say it was rounded to 9 digits instead?

?!? - sorry, I don't understand what you mean here. But the 73° case shows the roundoff problem very nicely:

So the 12-digit result is almost halfway between 1,27409035395 and ...96.
tan(1,27409035395) = 3,27085261842
tan(1,27409035396) = 3,27085261853

The latter is what you get on a 12-digit calculator where 73° "equals" 1,27409035396.

The calculator should return tan(1,27409035395586...) = 3,27085261848
But all it can calculate is tan(1,27409035395) = 3,27085261842    or    tan(1,27409035396) = 3,27085261853

The error in the result is the error in the argument (4,14E–12) times the tan derivative at this point (approx. 11,7), which yields 4,8E–11 or 5 units in the 12th digit – as you can see here: ...1848 vs. ...1853. Changing the argument by the smallest possible delta (1 ULP) makes the tangent change by 11–12 ULP (cf. ...1842 vs. ...1853).

Dieter
Pages: 1 2
Reference URL's
• HP Forums: https://www.hpmuseum.org/forum/index.php
• :