[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
Raymond Hettinger
report at bugs.python.org
Thu Jan 10 02:58:47 CET 2008
Raymond Hettinger added the comment:
> Decimal.from_rational(Rat(1, 3)) wouldn't be lossless
It should be implemented as Decimal(1)/Decimal(3) and then let the
context handle any inexactness.
> Rational.from_decimal is easier than from_float.
Yes. Just use Decimal.as_tuple() to get the integer components.
> Then Decimal.from_rational() could rely on just numbers.
> Rational, so it would be independent of this module.
>Is that a method you'd want on Decimal anyway?
Instead, just expand the decimal constructor to accept a rational input.
> Regarding float->rational, I propose to refuse Rational(1.1)
> for the same reasons as Decimal(1.1) is refused,
+1
> but to add a separate constructor (a class method?) that
> converts a float to a rational exactly (as long as it
> isn't nan or inf), large denominators be damned. This
> can help people who are interested in taking floating
> point numbers apart.
Here's how to pick the integer components out of a float:
mant, exp = math.frexp(x)
mant, exp = int(mant * 2.0 ** 53), exp-53
>> * Likewise, follow decimal's lead in avoiding all
>> automatic coercions from floats:
>> Rational(3,10) + 0.3 for example. The two don't mix.
> I'm reluctant to remove the fallback to float,
You will need some plan to scale-down long integers than exceed the
range of floats (right shifting the numerator and denominator until they
fit).
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________
More information about the Python-bugs-list
mailing list