PEP 238 (revised)

[Guido van Rossum]

Mark Day <mday at apple.com> writes:

> I assume that means type(long//int) == type(int//long) == long.

Yes, no different than for other operations with mixed arguments.

> Can we assume that when both arguments are integers (including long
> integers), that the result is exact (and that no part of the
> computation involves conversion to floats)?  That is, would we get the
> same result as "classic" division?

The result of //, yes, of course.

> >     - Let / keep its classic semantics; introduce // for true
> >       division.  This doesn't solve the problem that the classic /
> >       operator makes it hard to write polymorphic numeric functions
> >       accept int and float arguments, and still requires the use of
> >       x*1.0/y whenever true divisions is required.
> 
> I don't understand this statement.  Wouldn't you use // when you
> wanted true division?  Why wouldn't // (true division) support
> polymorphic functions?

The PEP has a mistake here -- the part "and still requires the use of
x*1.0/y whenever true divisions is required" is wrong; I'll fix this.
But it still leaves a broken operator in the language, and also shuts
off the road to a unified numeric model a la PEP 228.

> All I can see that's missing (compared to the actual proposal) is
> floor division that returns the same type as the (coerced)
> arguments.  That seems like it wouldn't be *too* hard: just use
> classic division (/ in this case) and if the result wasn't an
> integer, just call floor().  I suppose you could modify floor()
> [yuck!] or introduce a new function that returns the same type as
> its operand.  Is it that important to provide a type-preserving
> floor division?  (If you're assuming floor division, wouldn't you
> also use either int(a/b) or floor(a/b)?)

Other posts have explained the problem with making the result of
floor() exact.

> > Semantics of True Division
> > 
> >     True division for ints and longs will convert the arguments to
> >     float and then apply a float division.  That is, even 2/1 will
> >     return a float (2.0), not an int.
> 
> Well, then I'd call it Float Division.

I don't want to call it that for a specific reason: I want to keep the
door open to *possibly* introducing rationals and making 1/2 return a
rational rather than a float.  See PEP 239.

> This has the downside of loosing accuracy when the arguments are longs
> and the result can be expressed exactly as a long.

When you want an exact result there, you should use //.

> It would be nice if there was a division that would return exact
> results of the same type as the coerced arguments (when an exact
> answer is possible in that type).  But that begs the question of
> what you'd want in the case of division of two longs that can't be
> represented exactly in either a long or a float.  I guess I'd lean
> towards a long result (i.e. like classic division).

Rationals would give you that.

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