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

Guido van Rossum guido@python.org
Wed, 02 Oct 2002 20🔞28 -0400

python-pep@ccraig.org <python-pep@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/)