PEP239 (Rational Numbers) Reference Implementation and new issues

[John Roth]

<python-pep at ccraig.org> wrote in message
news:mailman.1033596730.13955.python-list at python.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.

And I don't think you're ever going to get a concensus, for the
simple reason that integer division is an oxymoron. The integers
are not closed under division. The rationals are, and so are the floats
(well, close enough.)

In other words, there is no right answer. Treating an integer
as a degenerate rational makes it look like integer 'division' should
return a rational, but that's simply semantics. You can just as easily
treat an integer as a degenerate float.

The basic issue that there are three separate styles of
arithmetic that give different results on important corner cases.
It's seldom obvious from the program text which is being used,
causing all kinds of confusion.

What I would _perfer_ to do is ban integer division completely,
and replace it by a set of specialty operations that each return
an explicitly defined result type: that is, fdiv, rdiv, idivf, idivr,
idivc.
I doubt that I'll get very much support for this, however.

So I'll vote on leaving it the way it currently is, until Python
3000. That's strictly for compatibility reasons. I see no reason
to force program changes.

John Roth
>
>    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
>
> 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).
>
> [1]
http://sourceforge.net/tracker/?func=detail&aid=617779&group_id=5470&ati
d=305470
>
> --
> Christopher A. Craig <python-pep at ccraig.org>
> "[Windows NT is] not about 'Where do you want to go today?'; it's more
like
> 'Where am I allowed to go today?'" -- Mike Mitchell, NT Systems
Administrator
>