[Numpy-discussion] Re: numpy, overflow, inf, ieee, and rich comparison

[Chris Barker]

> >> I have not yet heard a decent response to the question of what to do
> >> when a single value in a large array is bad, and causes an exception.
> 
> I'd usually trace back and try to figure out how it got "bad" to begin with

And from Konrad Hinsen
>I'd like to have at least the option of raising an exception in that
>case. Note that this is not what NumPy does today.

Exactly. This was Huaiyu's point. The problem is that for your code to
be usable for folks other than yourself, you'd have to have a lot of
checks in there, and essentially revert to elementwise code, which would
kill you. With the addition of the occasional "isnan" and something like
Matlab's "any" ( "any(isnan(A))" returns true if any of the elements of
A are NaNs) you could set up your code to raise an exception in the
middle of computation. If, on the other hand the Code definiately raises
an exception, than you are stuck with a lot of elementwise coding.

> over/under-flows in IDL are reported but do 
> not stop execution.  This is the best (only) possible scenario for an 
> interactive arrays and visualization environment.

Exactly!!! ("the best (only) possible scenario" part)
 
> IDL> print, 54/0
>       54
> % Program caused arithmetic error: Integer divide by 0

This, however, is wierd!!  54/0 == 54 ??? I'd much rather see a NaN or
Inf here!

> MATLAB is fine for simple interactive data processing, and its
> behaviour is adapted to this task. I don't think anyone would use
> MATLAB for developing complex algorithms, its programming language
> isn't strong enough for that. Python is, so complex algorithms have to
> be considered as well. And for that kind of application, continuing a
> calculation with Infs and NaNs is a debugging nightmare.

People do some pretty complex algorith develpment with MATLAB. I'm also
no so sure about "continuing a calculation with Infs and NaNs is a
debugging nightmare" I'm don't think it's any more of a nighmare than
having your calculation on an entire array stop because of one Inf. It's
just a different trade off. Sprinkle a few "isnan"'s in there and and
you can get the behaviour you want, while not forcing it on all
calculations. Of course, the best option is to have it switchable, but
that may prove to be very difficult.

Are people doing the kind of numeric programming with "complex
algorithms" using Python that Konrad refers to? More importantly, how
many people?

>  Guido thinks that 2/3 returning 0 was a design mistake,
> but not that math.sqrt(-1) raising an exception is a mistake.  Most Python
> users won't know what to do with a complex number, so it's "an error" to
> them.

Guido's philosophy is clearly that Python defaults should be geared to
"Most Python users". I agree, and as I wrote in an earlier post, the
only users for whom the "exception raising only" option is best are the
users Konrad refers to as writing "complex algorithms". I would argue
that those users are few, and the group most able to deal with a
less-that-optimum system.

Maybe we can have true 754 compliance in Py3k, and we can all be happy!!

-Chris





-- 
Christopher Barker,
Ph.D.                                                           
cbarker at jps.net                      ---           ---           ---
http://www.jps.net/cbarker          -----@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Water Resources Engineering       ------   @    ------   @   ------   @
Coastal and Fluvial Hydrodynamics -------      ---------     --------    
------------------------------------------------------------------------
------------------------------------------------------------------------