On Feb 25, 9:41 am, Mensanator <[EMAIL PROTECTED]> wrote: > On Feb 25, 12:58�am, Carl Banks <[EMAIL PROTECTED]> wrote: > > > > > On Feb 24, 10:56 pm, Mensanator <[EMAIL PROTECTED]> 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 rational. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
