How about adding rational fraction to Python?

Carl Banks pavlovevidence at
Mon Feb 25 17:18:32 CET 2008

On Feb 25, 9:41 am, Mensanator <mensana... at> wrote:
> On Feb 25, 12:58�am, Carl Banks <pavlovevide... at> wrote:
> > On Feb 24, 10:56 pm, Mensanator <mensana... at> wrote:
> > > But that doesn't mean they become less manageable than
> > > other unlimited precision usages. Did you see my example
> > > of the polynomial finder using Newton's Forward Differences
> > > Method? The denominator's certainly don't settle out, neither
> > > do they become unmanageable. And that's general mathematics.
> > No, that's a specific algorithm. �That some random algorithm doesn't
> > blow up the denominators to the point of disk thrashing doesn't mean
> > they won't generally.
> > Try doing numerical integration sometime with rationals, and tell me
> > how that works out. �Try calculating compound interest and storing
> > results for 1000 customers every month, and compare the size of your
> > database before and after.
> Nobody said rationals were the appropriate solution
> to _every_ problem, just as floats and integers aren't
> the appropriate solution to _every_ problem.

I was answering your claim that rationals are appropriate for general
mathematical uses.

> Your argument is that I should be forced to use
> an inappropriate type when rationals _are_
> the appropriate solution.

I don't know where you got that idea.

My argument is that rationals aren't suitable for ordinary uses
because they have poor performance and can easily blow up in your
face, trash your disk, and crash your program (your whole system if
you're on Windows).

In other words, 3/4 in Python rightly yields a float and not a

Carl Banks

More information about the Python-list mailing list