[Python-Dev] Floor division

[Nick Maclaren]

"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 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).

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