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

[Tim Peters]

[David M. Cooke]
> ...
> Even on glibc+Linux, it depends on the optimizations: for my machine
> running Linux-Mandrake 7.1 (glibc 2.1.3):
>
> Without -lieee, and without -O, I get your results above.
>
> Without -lieee, but compiled with -O, I get
>   x       exp(x)     errno   errmessage
> -745.0  4.94066e-324    0    Success
> -746.0             0    0    Success
>  709.0  8.21841e+307    0    Success
>  710.0           inf    0    Success
> sqrt( -1.0) =   nan,    0    Success
>
> However, on my Debian machine (with glibc 2.1.94) I get the first
> behaviour for compiling with -O (and higher). The compilers are both
> gcc 2.95.2.

You'll find that it also varies according to the processor chip, not just
the OS and compiler combo.  Indeed, on a WinTel box using the MS compiler,
you'll see different *numeric* results (let alone exception behavior) for
many non-exceptional inputs, depending on optimization.  For reasons that
have never made a lick of sense to me, MS tends to exploit (as they should)
the Pentium builtins with -O, but use their own software library routines
without -O, and they don't always agree.  It's a delight <wink>.  Your -O
no -lieee Mandrake 7.1 glibc 2.1.3 result above for sqrt(-1.0) *probably* (I
can't be sure without actually trying it) will end up (and incorrectly so)
raising OverflowError by the time Python math.sqrt(-1.0) is done with it,
despite that errno wasn't set.  This is an accident, depending on subtle
details of how the compiler happens to generate fp comparison code.  I'm
sure on *some* combo today we could find Python returning a NaN for
sqrt(-1.0).

> This is the reason exp behaves differently in Python on my work
> machine (with Linux-Mandrake) and on my home machine (with Debian):
> Mandrake compiles Python with optimizations (more severe than -O).
> This was a pain in the a** for some numerical code I was writing.

I'm afraid it appears that it nay still be a pain in the art for you even
under 2.0, since your non-lieee -O C results suggest that Mandrake 7.1's
policy is to ignore the C and POSIX stds under -O (which both require
setting errno to ERANGE or EDOM in some of these cases).  Alas, before we
get real 754 support, errno is the only thing Python has to look at.  It
would be interesting to know whether your Mandrake system already fails the
std Python test_libm test under current CVS Python (I'm betting it will).

that's-what-you-get-when-you-let-os-dorks-design-math-libraries<wink>-ly
    y'rs  - tim