On Feb 24, 10:34�pm, casevh <[EMAIL PROTECTED]> wrote: > 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.
Well, that applies equally to Python long ints which can be intractable compared to gmpy's long ints. > 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. Well, _I_ don't expect constant run time, but I usually need tractable run-time. And since Python's built-ins can't always cut it compared to gmpy, I suppose a fraction type probably couldn't hold a candle to gmpy either. So even if implemented correctly to prevent runaway denominators, the fraction type would likely end up being as worthless to me as the current long ints are. > > There are trade-offs between IEEE-754 binary, Decimal, and Rational > arithmetic. They all have there appropriate problem domains. Of course. And design decisions shouldn't be based on bad algorithms, but those that are appropriate to the problem domain. > > And sometimes you just need unlimited precision, radix-6, fixed-point > arithmetic.... > > casevh -- http://mail.python.org/mailman/listinfo/python-list
