[Python-Dev] Floor division (original) (raw)

Nick Maclaren nmm1 at cus.cam.ac.uk
Tue Jan 23 10:58:06 CET 2007

"Tim Peters" <tim.peters at gmail.com> wrote:

> 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? That's wrong, if true: it should return something with the opposite sign on the imaginary part, whether or not that equals 0 (+0. and -0. both "equal 0").

Grrk. Why? Seriously. IEEE 754 signed zeroes are deceptive enough for float, but are a gibbering nightmare for complex; Kahan may be able to handle them, but mere mortals can't. Inter alia, the only sane forms of infinity for complex numbers are a SINGLE one (the compactified model) and to may infinity into NaN (which I prefer, as it leads to less nonsense).

And, returning to 'floor' - if one is truncating towards -infinity, should floor(-0.0) deliver -1.0, 0.0 or -0.0?

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.

Eh? No, it isn't. Because of the indirection to the C library, it is changing specification as we speak! THAT is all I am getting at; not that the answer might not be A math.fmod with defined behaviour.

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.

I never said that it should; I said that it is reasonable behaviour on systems that support them. I personally much prefer an exception in this case. What I was trying to point out is that the current behaviour is UNDEFINED (and may give total nonsense). That is not good.

>> 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 1050000 is exactly 1050000 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).

Eh? I don't understand. Are you referring to float("1.0e50000"), pow(10,50000), pow(10.0,50000), or a conjugate (and, if so, of what?)

float(conjg(1.23)) obviously need not raise an exception, except possibly "Sanity failure" :-)

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