[Python-Dev] Floor division

Tim Peters tim.peters at gmail.com
Tue Jan 23 08:28:20 CET 2007


[Guido]
>> That really sucks, especially since the whole point of making int
>> division return a float was to make the integers embedded in the
>> floats... I think the best solution would be to remove the definition
>> of % (and then also for divmod()) for floats altogether, deferring to
>> math.fmod() instead.

[Nick Maclaren]
> Please, NO!!!
>
> At least not without changing the specification of the math module.
> The problem with it is that it is specified to be a mapping of the
> underlying C library, complete with its <censored> error handling.
> fmod isn't bad, as <math.h> goes, BUT:
>
> God alone knows what happens with fmod(x,0.0), let alone fmod(x,-0.0).
> C99 says that it is implementation-defined whether a domain error
> occurs or the function returns zero, but domain errors are defined
> behaviour only in C90 (and not in C99!)  It is properly defined only
> if Annex F is in effect (with all the consequences that implies).
>
> Note that I am not saying that syntactic support is needed, because
> Fortran gets along perfectly well with this as a function.  All I
> am saying is that we want a defined function with decent error
> handling!  Returning a NaN is fine on systems with proper NaN support,
> which is why C99 Annex F fmod is OK.

math.fmod is 15 years old -- whether or not someone likes it has
nothing to do with whether Python should stop trying to use the
current integer-derived meaning of % for floats.

On occasion we've added additional error checking around functions
inherited from C.  But adding code to return a NaN has never been
done.  If you want special error checking added to the math.fmod
wrapper, it would be easiest to "sell" by far to request that it raise
ZeroDivisionError (as integer mod does) for a modulus of 0, or
ValueError (Python's historic mapping of libm EDOM, and what Python's
fmod(1, 0) already does on some platforms).  The `decimal` module
raises InvalidOperation in this case, but that exception is specific
to the `decimal` module for now.

>> For ints and floats, real could just return self, and imag could
>> return a 0 of the same type as self. I guess the conjugate() function
>> could also just return self (although I see that conjugate() for a
>> complex with a zero imaginary part returns something whose imaginary
>> part is -0; is that intentional? I'd rather not have to do that when
>> the input is an int or float, what do you think?)

> I don't see the problem in doing that - WHEN implicit conversion
> to a smaller domain, losing information, raises an exception.

Take it as a pragmatic fact that it wouldn't.  Besides, e.g., the
conjugate of 10**50000 is exactly 10**50000 mathematically.  Why raise
an exception just because it can't be represented as a float?  The
exact result is easily supplied with a few lines of "obviously
correct" implementation code (incref `self` and return it).


More information about the Python-Dev mailing list