[Python-Dev] Floor division

Nick Maclaren nmm1 at cus.cam.ac.uk
Mon Jan 22 19:14:16 CET 2007


"Guido van Rossum" <guido at python.org> wrote:
>         
> 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.

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.

> 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.  The
errors caused by needing a 'cast' (including Fortran INT, DBLE and
(ugh) COMPLEX, here) causing not just conversion but information
loss have caused major trouble for as long as I have been around.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679


More information about the Python-Dev mailing list