Home Original page

[Python-Dev] PEP239 (Rational Numbers) Reference Implementation and new issues

Eric S. Raymond esr at thyrsus.com
Wed Oct 2 18:14:21 EDT 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 [1].  I do have some new issues for
> discussion that I'd like to get some comments on before I change the
> PEP.
> 
> 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 mailing list