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

[Guido van Rossum]

> 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

[ESR]
> +1 for returning rationals.  It's the right thing -- and if it fails, 
> it will fail noisily, right?

Not clear at all.  ABC did this, and we found that a common problem
was that a program doing numeric stuff would run very slowly (i.e. the
opposite of failing noisily).

How are you going to print rationals?  If str(1/3) (and hence print
1/3) or repr(1/3) will return "1/3", that is surely going to cause a
huge amount of breakage.

> > 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.

It's not at all clear that that's the right solution.  The problem
with a fuzz variable is that there's only one, and library modules may
end up fighting over the right value for what they are trying to
accomplish.  Making it a per-module variable causes the opposite set
of problems.

I'm all for adding rationals to the language -- but I'd like them
segregated until we have a lot more experience with how they behave.

--Guido van Rossum (home page: http://www.python.org/~guido/)