Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!feeder.news-service.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Gregory Ewing Newsgroups: comp.lang.python Subject: Re: Faster Recursive Fibonacci Numbers Date: Sat, 21 May 2011 20:49:33 +1200 Lines: 30 Message-ID: <93pcl0Fe1nU1@mid.individual.net> References: <108ce447-10fa-4cf7-84ef-440ee18dbfd4@22g2000prx.googlegroups.com> <9d9c163b-14fd-4131-81bb-105c3b97c432@h36g2000pro.googlegroups.com> <4dd59e1e$0$29996$c3e8da3$5496439d@news.astraweb.com> <4dd602ec$0$29996$c3e8da3$5496439d@news.astraweb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net ftTNBJaST9z6ByVXCdXJegB/VemF45xnNyX+8NN9DBYkeykWbd Cancel-Lock: sha1:7OBN+IpO0FFmz/TGueSmbECgDCQ= User-Agent: Mozilla Thunderbird 1.0.5 (Macintosh/20050711) X-Accept-Language: en-us, en In-Reply-To: Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:5908 Chris Angelico wrote: > It seems > strange to smoothly slide from native integer to long integer and just > keep on going, and yet to be unable to do the same if there's a > fractional part on it. The trouble is that if you always compute exact results by default, the number of digits required can blow up very quickly. There's a story that ABC (the predecessor to Python) calculated everything using rationals. People found that sometimes a calculation would take an unexpectedly long time, and it turned out to be because internally it was creating fractions with huge numerators and denominators. As a consequence, Guido decided that Python would *not* use rationals by default. The same problem doesn't arise with ints, because the only time you get an int with a large number of digits is when you genuinely need a large int. So expanding ints automatically to however many digits is needed doesn't do any harm. In Python 2.6 and later, there's a fractions module for when you need it. -- Greg