Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)

[Tim Peters]

[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