How about adding rational fraction to Python?

[casevh]

On Feb 24, 7:56 pm, Mensanator <mensana... at aol.com> 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