numpy, overflow, inf, ieee, and rich comparison

[Tim Peters]

[Huaiyu Zhu]
> I'm stumbling over a seemingly trivial problem.

Sorry, but nothing about x-platform floating-point is trivial.  Although,
ya, it *should* be.

> ...
> We know that exp(-1000) is approximately zero to machine precision.

That depends on your hardware.

> However, on my machine
>
> >>> from math import *
> >>> exp(-745)
> 4.9406564584124654e-324
> >>> exp(-746)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> OverflowError: math range error

While that's inherited from your libc.  On Windows, with MS's libraries:

>>> import math
>>> math.exp(-746)
0.0
>>> math.exp(-1000)
0.0
>>> math.exp(-1e300)
0.0
>>>

> Now, for this simple example, it is easy to add an if statement.
> But for a Numeric.array, which has the same problem, an if statement
> obviously does not work, in the sense that it defeats all the speed
> gains.

I haven't used Numeric, but I do guess you're simply hosed without resorting
to C.

> So the first question is: Can this be avoided?  My understanding is that
> this is the issue of the underlying C library and cannot be avoided unless
> we are willing to rewrite it.

C89 was fatally fuzzy about almost all floating-point issues, so there's
unfortunately little that Python does for you beyond passing on your libc's
particular delusions.  From the above, it appears that an underflowing exp
on your platform sets errno to ERANGE, while it does not under Windows.
Python explicitly sets errno to 0 before calling libc/libm math functions,
and checks errno (among other things) when the platform functions return.
So in this particular case, you could use a variant of mathmodule.c where
math_1 and math_2 (generic drivers) are changed simply to stop checking
errno!  That is, change the few blocks that look like

	if (errno != 0)
		return math_error();
	else
		return PyFloat_FromDouble(x);

to

	return PyFloat_FromDouble(x);

There are other layers of checking, though, that may still get in your way.

There's more than a bit of irony here:  754 arithmetic was designed from the
ground up to make writing robust numeric algorithms much easier than they
had been before.  But Python's multiple layers of "catch and complain" about
every little numeric endcase fight the 754 view to the death.  The irony is
that the "catch and complain" code was mostly contributed by
number-crunchers.

So, by the time you guys stop stabbing each other in the back <0.9 wink>,
perhaps C99 will be widely implemented enough that Python can actually do
something useful for you here.

> ...

no-answers-ly y'rs  - tim