On Feb 24, 7: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. >
Since you are expecting to work with unlimited (or at least, very high) precision, then the behavior of rationals is not a surprise. But a naive user may be surprised when the running time for a calculation varies greatly based on the values of the numbers. In contrast, the running time for standard binary floating point operations are fairly constant. > > If the point was as SDA suggested, where things like 16/16 > are possible, I see that point. As gmpy demonstrates thouigh, > such concerns are moot as that doesn't happen. There's no > reason to suppose a Python native rational type would be > implemented stupidly, is there? In the current version of GMP, the running time for the calculation of the greatest common divisor is O(n^2). If you include reduction to lowest terms, the running time for a rational add is now O(n^2) instead of O(n) for a high-precision floating point addition or O(1) for a standard floating point addition. If you need an exact rational answer, then the change in running time is fine. But you can't just use rationals and expect a constant running time. There are trade-offs between IEEE-754 binary, Decimal, and Rational arithmetic. They all have there appropriate problem domains. And sometimes you just need unlimited precision, radix-6, fixed-point arithmetic.... casevh -- http://mail.python.org/mailman/listinfo/python-list
