On Sat, Sep 20, 2014 at 9:38 AM, Alexander Belopolsky
<report@bugs.python.org> wrote:
>
> Alexander Belopolsky added the comment:
>
>> Perhaps it's worth mentioning that several people on Python-ideas
>> took the opposite view:  math.floor() should return a float.
>
> I sympathize with the idea that math module functions should return floats.  I find it unfortunate that math.floor delegates to the __floor__ dunder on non-floats instead of doing math.floor(x.__float__()).  It would be more natural to have a floor builtin that *always* delegates to __floor__ and keep math a pure float library.

+1

>
> Note that math module provides the means to compute C-style floor:
>
>>>> x = float('inf')
>>>> math.modf(x)[1]
> inf
>>>> x = -3.4
>>>> math.modf(x)[1]
> -3.0

That's not immediately obvious...

>
> Maybe we should add floorf, ceilf, etc. as well.  This, however, is a different issue from the one at hand here.
>

i think the issues are related. PEP-3141 defines x//y as
int(floor(x/y)). It also defines divmod(x, y) as (x//y, x % y). These
definitions cannot all be satisfied at the same  Python's divmod
function takes extra effort to calculate x//y precisely. Those
corrections are not possible via floor().

I maintain gmpy2 which wraps the GMP, MPFR, and MPC arbitrary
precision libraries. I originally implemented x//y as floor(x/y). That
choice lead to errors in divmod() that I've fixed in the development
version. I still need to fix floor division: do I make it compatible
with divmod() or floor()?

My preference would be to define floor division and divmod in terms of
each other and allow math.ceil()/floor()/trunc() to return floating
point values. The current definitions are impossible to satisfy.

I mentioned my concerns about memory growth in another comment. I'm
not as concerned about the unexpected memory growth in floor division
as I am in floor() etc.