Possible solution for IEEE754? (was Re: numpy, overflow, inf, ieee, and rich comparison)

[Huaiyu Zhu]

There is a miniproposal to use IEEE754 arithmetic near the end of this long
article.

On Tue, 10 Oct 2000 07:01:40 -0400, Tim Peters <tim_one at email.msn.com> wrote:

>> [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2

>I'm not enough of a collector of gcc trivia to see at once that egcs-2.91.66
>is exactly the same as egcs-1.1.2, but if you say so ...

The gcc version is egcs-2.91.66, provided in the rpm package egcs-1.1.2

# /usr/bin/gcc --version
egcs-2.91.66
# rpm -qf /usr/bin/gcc
egcs-1.1.2-24

[About why python1.5.2 and python2.0 behaves differently in math.exp]

>Can't answer your question.  It's a platform-dependent crap shoot, and in
>any case is usually entirely due to the libraries you're linking with and
>nothing to do with the compiler.  Do you have any way to tell which
>libraries you're using in the two cases?  Can you still get at them?  If so,
>write a little C program to do the same thing, and see whether exp sets
>errno there.

Here's the result for the gcc I used to compile Python 2.0
    x       exp(x)     errno   errmessage
  -744.0  9.88131e-324    0  Success
  -745.0  4.94066e-324    0  Success
  -746.0             0   34  Numerical result out of range
  -747.0             0   34  Numerical result out of range

So does this mean that Python 1.5.2 that shipped with RedHat was built to
link to a different library than the one gcc links to?  This sounds
extremely unlikely, as the Python rpm does not seem to depend on libc
compatibility packages.

Any RedHat users out there to test this behavior of gcc? (C code below)

>
>The CVS history of mathmodule.c is available online, 
...
>From that, you can see that math_1 has been raising an error on non-zero
>errno since Sun Oct 14 12:07:23 1990 (i.e., since the beginning of RPT
>(Recorded Python Time)).  The 1.5.2 version is revision 2.42.  Nothing
>interesting about Python's math.exp has changed since then on any platform.

Is this the only place that errno is checked for numerical stuff?  What
about the following change that ignores math range error when math behaves
as IEEE 754.

#ifdef IEEE754
    if (errno != 0 && errno != ERANGE)
#else    
    if (errno != 0)
#endif

These are the only places that uses math_error():

./Modules/cmathmodule.c:317:math_error(void)
./Modules/cmathmodule.c:341:return math_error();
./Modules/mathmodule.c:30:math_error(void)
./Modules/mathmodule.c:54:return math_error();
./Modules/mathmodule.c:71:return math_error();
./Modules/mathmodule.c:147:return math_error();
./Modules/mathmodule.c:172:return math_error();
./Modules/mathmodule.c:201:return math_error();

The remaining problem is only to tell when to define IEEE754, which
presumably is a simpler problem.  In any case, users who want to do this
could just #define IEEE754 somewhere.  Is this a good solution?  

I understand that there are more details to IEEE 754 than this, but wouldn't
this be far better than raising an exception when something is approximately
zero?  

Here' the C code to check errno of exp:

#include <stdio.h>
#include <math.h>
#include <errno.h>
main () {
  double x, y;
  printf("  x       exp(x)     errno   errmessage\n");
  for (x=-744; x>-748; x--)
    {
      y = exp(x);
      printf("%.1f %13.6g  %3d  %s\n", x, y, errno, strerror(errno));
    }
  return 0;
}

Huaiyu