I've searched the archive and came up with several discussions of the log bug using large numbers, but didn't find anything about trig functions of large numbers. In particular, try taking the cosine of :

2pi x10^8

2pi x10^9

2pi x10^10

etc.

Apologies if this has already been beaten to death. If so, I must have been asleep at the wheel.

CHUCK

Hello,
same at 50g, 48g+ but beyond 10^11. And no such behaviour at the ti89 - always 1.
Michael

Edited: 13 Jan 2009, 6:28 p.m.

Interesting...

My first instinct would be to say that as the coefficients of 2pi get bigger, progressively more of the calculators available numerical precision is taken up by the integer portion of the resultant large number. And of course the fractional part of pi is what defines that irrational constant...the more decimal places, the better. As you truncate decimal places, you loose accuracy, etc. What's interesting here is that if I reduce the domain manually to <2pi of any of the three figures you cited (by dividing by 2pi and multiplying the remainder (or fractional part) by 2pi). I always get zero, and hence a cosine of 1. I tried this in exact mode, carrying pi symbolically throughout, and also in approximate mode, carrying pi numerically. In fact, this proved to be the case for 2pi multiplied by any exponent of ten. I think this is simply because the fractional part of any number bigger than about 15 digits is always zero (as for as the calculator is concerned). This works out well for any even multiple of 2pi, but would be disastrous for anything else, (such as 2pi x10^25 + pi/4), which explains why the calculator obviously doesn't use this method for normalization of large arguments for trig functions.

For what it's worth, I did note that accuracy for trig functions in degree mode is dead on for 360*10^x for x=0-497 :)

Best regards, Hal

Hi, Chuck --

Quote:

---

In particular, try taking the cosine of :

2pi x10^8

2pi x10^9

2pi x10^10

etc.

Things start to break down around 8 and 9, and become totally unpredictable beyond 11.

---

Of course, these calculations should be assumed in radians mode, and the answer should always be unity as long as pi is exact. However, this is not the case unless pi is treated symbolically. Accuracy of the input-argument angle is limited by the 12 significant digits; there is absolutely no fractional part left after being "consumed" by a power-of-10 multiplier of 11 or greater.

Quote:

---

I've searched the archive and came up with several discussions of the log bug using large numbers, but didn't find anything about trig functions of large numbers.

---

Nothing for the HP-35s, but two discussions took place in 2007 on this topic. Both links point to a post of mine, but you can review the entire or pertinent threads:

sin(60!)

Trigonometrics for Really Big Input

-- KS

Edited: 14 Jan 2009, 3:42 a.m.

Hi Karl

Quote:

---

Of course, these calculations should be assumed in radians mode, and the answer should always be unity as long as pi is exact. However, this is not the case unless pi is treated symbolically. Accuracy of the input-argument angle is limited by the 12 significant digits; there is absolutely no fractional part left after being "consumed" by a power-of-10 multiplier of 11 or greater.

---

Quote:

---

I can't get my 50G to return unity for the expression cos(2pi*1.E12), even though it appears to be carrying pi symbollically. It seems that 1E12 becomes the non integer value 1.E12 when entered (as evidenced by the decimal point). Therefore when I evaluate the expression, the calc switches to approx mode, and returns .9157108. The CAS setting "Simp non rationals" has no effect. Any insight on this?

---

Hal --

I'm no expert on RPL, but I have an HP-49G that performs similarly.

Pi is approximated by a 12-digit value when "->NUM" is executed. Evaluating 'SIN(pi)' on the HP-49G yields -2.0661537357E-13, just as on an HP-42S, where this is done numerically.

EXACT mode may apply only to integers, which allows (for example) every digit of 60! to be calculated.

-- KS

Edited: 15 Jan 2009, 12:59 a.m.

Quote:

---

Pi is approximated by a 12-digit value when "->NUM" is executed. Evaluating 'SIN(pi)' on the HP-49G yields -2.0661537357E-13, just as on an HP-42S, where this is done numerically.

---