Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
Tim Peters
tim_one at email.msn.com
Thu Oct 12 00:18:19 EDT 2000
[William Park]
> On Wed, Oct 11, 2000 at 10:44:20PM -0400, Tim Peters wrote:
> > > Likewise sqrt(-1.) needs to stop, not put a zero and keep going.
I didn't write that. Paul Dubois did.
> Hmm... I don't like this. It should stop or return complex.
Paul said it should stop. You said it should stop (or return complex). So
what is it that you don't like <wink/frown>? 754 mandates that sqrt(x) for
x<0 return a NaN and keep going (by default) -- which even Huaiyu apparently
doesn't like.
[actually Tim]
> I have no idea what gcc+glibc+Linux did here on 1.5.2, but it *should*
> have silently returned a NaN (not a zero) without setting errno if it
> was *self*-consistent -- anyone care to check that under -lieee?:
>
> import math
> math.sqrt(-1)
>
> NaN or ValueError? 2.0 should raise ValueError regardless of
> what 1.5.2 did here.).
[back to William]
> It returns 'OverflowError: math range error' in 1.5.2,
Ah, that's hilarious <wink>! It's tempting to believe that glibc is
violating the IEEE std despite the -lieee flag in this case, but I don't
believe that's true: it's almost certainly the case that glibc is actually
returning a NaN, *not* setting errno at all, and this other check in
Python's mathmodule.c:
#define CHECK(x) if (errno != 0) ; \
else if (-HUGE_VAL <= (x) && (x) <= HUGE_VAL) ; \
else errno = ERANGE
is setting errno to ERANGE purely due to an accident of the way gcc happens
to compile code for comparing NaN to Inf and -Inf.
> and 'ValueError: math domain error' in 2.0.
Which is the correct exception, so is another reason for Python to
avoid -lieee in 2.0.
will-be-easier-to-make-it-work-right-by-design-than-to-keep-doping-out-
what-happens-by-accident-now-ly y'rs - tim
More information about the Python-list
mailing list