HP 35s and Cosine of large numbers - Printable Version +- HP Forums (https://archived.hpcalc.org/museumforum) +-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html) +--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html) +--- Thread: HP 35s and Cosine of large numbers (/thread-145694.html) HP 35s and Cosine of large numbers - Chuck - 01-13-2009 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.``` Things start to break down around 8 and 9, and become totally unpredictable beyond 11. The TI8x series skirts this issue by giving a domain error for anything beyond 1x10^11. Granted, there may be no practical purpose for arguments of this magnitude, but still is amusing, if not alarming. Apologies if this has already been beaten to death. If so, I must have been asleep at the wheel. CHUCK Re: HP 35s and Cosine of large numbers - Michael - 01-13-2009 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. 35s...Cosine of large numbers - Hal Bitton in Boise - 01-14-2009 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 Re: HP 35s and Cosine of large numbers - Karl Schneider - 01-14-2009 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: -- KS Edited: 14 Jan 2009, 3:42 a.m. Math Curiousity...an old fashioned approach - Hal Bitton in Boise - 01-14-2009 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. 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). Therefor 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? Best regards, Hal Re: Math Curiousity...an old fashioned approach - Karl Schneider - 01-15-2009 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. I think I found a way - Hal Bitton in Boise - 01-15-2009 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. Indeed Karl...The same result I get, unless I leave pi in symbolic form, in which case Sin(symbolic pi) evaluated to zero. My quandary had been how to get the calculator to treat exponents of 10 entered with the EEX key as exact integers, which would seem a logical thing, but which apparently it will not do. I think I have found a workaround, however. Once the expression is entered, use the ->Q function to convert it to an exact integer. Then the calc will treat the entire expression symbolically, with the expected ideal results. For example: key in 2*(symbolic pi)*1.0E12 (using the EEX key) , and execute ->Q, which will return: 2*(symbolic pi)*1000000000000 Now, take the cosine of this, and eval, and low and behold, the much sought after unity is returned. The accuracy does not degrade with bigger coefficients, either...2*(symbolic pi)*1.0E450 ->Q COS EVAL returns 1. Best regards, Hal