proposed language change to int/int==float (was: PEP0238 lament)

[Guido van Rossum]

Gareth.McCaughan at pobox.com (Gareth McCaughan) writes:

> I am a mathematician, and I do not know, or even believe,
> that "float division is nothing more than a logical extension
> of integer division" if "integer division" means what
> Python presently does.

Thanks.  I am baffled by the many claims that for mathematicians 1/2
equals zero; I've never met such a mathematicians.

> To any mathematician on the planet, 1/2 is, well, 1/2.
> A rational number quite different from 0.

Right.

> This isn't necessarily an argument for making division
> return rationals when handed integers -- well, it is, but
> it's not necessarily a very *strong* argument for that.
> (It would involve a non-trivial amount of work, the
> results would be amazingly frustrating in practice
> unless the numerator and denominator had the sematics
> of longs rather than ints, and simple programs could
> become mysteriously inefficient. Some people would find
> that worse than them just doing the wrong thing.)

Certainly any suggestion of rationals presumes the use of long ints.
The mysterious inefficiency is also my experience with ABC.

> If I were re-designing Python from scratch and didn't
> care about backwards compatibility, then I'd give it
> unified ints and longs, and rationals, and I'd make
> division of integers produce rationals. But I'm not,
> and since Guido is a better language designer than me
> it's probably just as well.

Right!  In fact, the goal of PEP 238 is to make such a redesign of
Python's numeric system possible.  This is hinted at by PEP 228
(Reworking Python's Numeric Model).  Unfortunately, the motivational
sections in both PEPs are weak -- we never expected so much
opposition.

The interesting thing is that the one thing that has to change in
order to get a unified numeric model, whether we introduce rationals
in the numeric tower or not, is integer division!  A numeric tower
with rationals could look like this:

  int < long < rational < float < complex

(Note that float stands in for real -- I should have called it that,
in the grand tradition of Algol and Pascal.  But this design bug is
not worth fixing, since it doesn't lead to programming errors.)

Without rationals, it would look like this:

  int < long < float < complex

Either is acceptable to me; both have their share of problems.  A
later transition from a numeric tower without rationals to a tower
with rationals doesn't have to create much backwards compatibility:
the mathematical value of 1/2 is the same of that as 0.5, so an
algorithm that works when 1/2 returns 0.5 will still work (and perhaps
even more accurately!) when 1/2 returns, well, the rational number
1/2.

But PEP 238 can stand on its own.  If it is rejected, PEP 228 has no
chance; but PEP 238 can be accepted and PEP 228 rejected and the world
would still be a better place.

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