On Fri, May 20, 2011 at 10:07 AM, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > On Fri, 20 May 2011 16:54:06 +1000, Chris Angelico wrote: > >> If someone has time to kill (as if!), it'd be awesome to get a new >> numeric type that uses bc's code; any other numeric type (int, long, >> float) could autopromote to it, removing the dilemma of which to promote >> out of long and float. Hmm... Python 4.0, 'bc' is the new default >> integer and everything else is a performance optimization? Heh. > > The problem is, it isn't *just* a performance optimization, there is a > semantic difference too. Consider: > >>>> x = 1e-300 >>>> x*x == 0 > True > > But using something with more precision: > >>>> from fractions import Fraction >>>> x = Fraction(10)**-300 >>>> x*x == 0 > False > > > So you get different behaviour between floats and arbitrary precision > numbers.
And this shows up in the above implementation; reimplementing it using Fractions and a truncated continuing fraction approximation of phi and the square root of 5 gets us up to about 500, at the cost of a very long computation time. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
