[Python-Dev] PEP239 (Rational Numbers) Reference Implementation and new issues
Eric S. Raymond
esr at thyrsus.com
Thu Oct 3 00:14:21 CEST 2002
python-pep at ccraig.org <python-pep at ccraig.org>:
> I just uploaded a reference implementation of how rationals might look
> in Python as patch 617779 . I do have some new issues for
> discussion that I'd like to get some comments on before I change the
> 1) Should future division return rationals rather than floats. I had
> sort of assumed this would happen, but I just had a discussion with
> Kirby Urner and couldn't convince him it was a good idea, so I guess
> it isn't so clear.
> Arguments for:
> - you don't lose precision on divides
> - It provides a really nice way to specify rationals (i.e. 1/3)
> - It allows you to eventually unify int/long/rationals so that
> rationals with a denominator of 1 are automagically upcast.
> Arguments against:
> - people who have already changed their code to expect floats will
> have to change it again
> - rationals are slow
+1 for returning rationals. It's the right thing -- and if it fails,
it will fail noisily, right?
> 2) Should floats compare equal with rationals only when they are
> equal, or whenever the are the closest float? (i.e. will .2
> compare equal to rational(1, 5))
> 3) Should rationals try to hash the same as floats? My leaning on
> this is that it will be decided by (2). If they compare equal when
> 'close enough' then they should hash the same, if not then they should
> only hash the same when both are integral. I would rather not see .5
> hash with rational(1, 2) but not .2 with rational(1, 5).
APL faced this problem twenty-five years ago. I like its solution;
a `fuzz' variable defining the close-enough-for-equality range.
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
More information about the Python-list