"Tim Peters" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
Tel.: +44 1223 334761 Fax: +44 1223 334679
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
