HP 35s and Cosine of large numbers « Next Oldest | Next Newest »

 ▼ Chuck Senior Member Posts: 320 Threads: 59 Joined: Dec 2006 01-13-2009, 05:45 PM 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 ▼ Michael Junior Member Posts: 48 Threads: 15 Joined: Sep 2008 01-13-2009, 06:14 PM 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. Hal Bitton in Boise Senior Member Posts: 291 Threads: 43 Joined: Jun 2007 01-14-2009, 01:26 AM 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 Karl Schneider Posting Freak Posts: 1,792 Threads: 62 Joined: Jan 2005 01-14-2009, 03:39 AM 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. ▼ Hal Bitton in Boise Senior Member Posts: 291 Threads: 43 Joined: Jun 2007 01-14-2009, 04:07 PM 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 ▼ Karl Schneider Posting Freak Posts: 1,792 Threads: 62 Joined: Jan 2005 01-15-2009, 12:26 AM 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. ▼ Hal Bitton in Boise Senior Member Posts: 291 Threads: 43 Joined: Jun 2007 01-15-2009, 01:52 AM 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

 Possibly Related Threads... Thread Author Replies Views Last Post HP Prime: complex numbers in CAS. Alberto Candel 1 1,405 12-06-2013, 02:36 PM Last Post: parisse [HP Prime] Plots containing complex numbers bug? Chris Pem10 7 2,858 12-05-2013, 07:40 AM Last Post: cyrille de Brébisson Prime: size display bug when editing large programs BruceH 2 1,087 10-31-2013, 05:30 PM Last Post: BruceH HP Prime: How to use a large array in a program? HP Pioneer 2 1,116 10-27-2013, 03:15 AM Last Post: steindid comparing numbers on the WP 34S Kiyoshi Akima 7 1,990 10-19-2013, 09:28 AM Last Post: walter b HP Prime: Operations with Large Numbers Eddie W. Shore 0 762 10-19-2013, 12:24 AM Last Post: Eddie W. Shore HHC 2013 room numbers David Hayden 2 1,035 09-20-2013, 05:34 PM Last Post: sjthomas [HP-Prime xcas] operations with complex numbers + BUGs + Request CompSystems 9 2,866 09-08-2013, 10:40 PM Last Post: CompSystems TED Talk: Adam Spencer: Why I fell in love with monster prime numbers Les Bell 3 1,404 09-05-2013, 12:54 PM Last Post: Ken Shaw Irrationality in numbers....the book Matt Agajanian 4 1,497 08-30-2013, 04:14 PM Last Post: Matt Agajanian

Forum Jump: