Re: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)

[Guido v. R. <gu...@py...>]

> I don't have time to follow in detail this thread about changed behavior
> between versions. These observations are based on working with hundreds of
> code authors. I offer them as is.
> 
> a. Nobody runs a serious numeric calculation without setting
> underflow-to-zero, in the hardware. You can't even afford the cost of
> software checks. Unfortunately there is no portable way to do that that I
> know of.
> 
> b. Some people use Inf but most people want the code to STOP so they can
> find out where the INFS started. Otherwise, two hours later you have big
> arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to
> stop, not put a zero and keep going.

Thanks, Paul!  This behavior has always been what I wanted Python to
do (even though it's not always what Python did, depending on the
platform) and also what Tim's proposed patch will implement for the
specific case of math.exp() (and other math functions that may
underflow or overflow), on most reasonable platforms.

There are still lots of places where the platform gives Python no
choice of creating NaN and Inf, and because there's no
platform-independent way to test for these, they are hard to avoid in
some cases; but eventually, Tim will find a way to root them out.  And
for people like Huaiyu, who want to see Inf, there will (eventually)
be a way to select this as a run-time option; and ditto for whoever
might want underflow to raise an exception.

--Guido van Rossum (home page: http://www.python.org/~guido/)