Nasty typo in PEP 238 (revised)

[Guido van Rossum]

David Eppstein <eppstein at ics.uci.edu> writes:

> > >>    A. Use x*1.0/y for true division, divmod(x, y)[0] for int
> > >>       division.  Especially the latter is best hidden inside a
> > >>       function.  You may also write floor(x)/y for true division if
> > >>       you are sure that you don't expect complex numbers.
> > >>
> > > 
> > > 
> > > Shouldn't this be float(x)/y ?

Yes, it's a typo.

> > > I still don't like the phrase "true division", it implies a
> > > value judgement that quotients are somehow an inferior thing to
> > > want to compute.

I may go with your ratio.

> floor converts ints to floats????  This seems exactly backwards from what I 
> would expect.  And while it is certainly documented that way in the library 
> reference (section 5), it is contradicted by the footnote in section 2 
> about using floor and ceil for "well-defined conversions" from float to 
> int, as well as the claim in the reference manual that integer-division is 
> the same as applying floor to the result of mathematical division.

The floor() function is part of the math module, whose whole point is
to work with floats.  In the future, we may introduce a floor()
function in the standard library which should of course behave better.

> I have to consider this a big wart.
> Especially with the proposed changes to /, I would likely want to write 
> code like i = floor(a/b) and j = ceil(c/d) but apparently this is going to 
> need added coercions to get an integral type.

I hope you would use // rather than using floor().  For ceil(), I
guess you could use -(-c//d). :-(

> Anyway, back to the PEP, I don't think calling floor(x) is a very clear way 
> of writing an int-to-float coercion, and it's still a bug because it will 
> give you incorrect results if x is a non-integral float.

It was a typo.

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