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

[Chris Barker]

Incomplete vs. non-at-all IEEE 754 support is a non argument. If you
have full IEEE support (which it seems everyone here thinks would be
good, but difficult), it is clear what you have. If not, you are not
consistent with a standard, and therefor making up your own. That being
the case, it's a matter of what we want the Python standard to be.

I, for one think that NaN and Inf are fantastic!!! I think the best
argument for them here is that it is almost impossible to do a lot of
array based calculations without them, and you can't do serious number
crunching in Python without array based calculations.

I've come to Python from MATLAB for numerics, and I really appreciated
MATLAB's way of handling all this. I don't think MATLAB has true 754
support, as I don't think you can change the behaviour, but you do get a
consistent result across platforms (including non-iee machines like the
Cray?---I have no idea). 

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.
This really does render Python essentially useless for Numerics for me.
I suspect all those number crunchers that want an exception rather than
an Inf are NOT using array-oriented languages. My goal is to dump MATLAB
for Python, but this may prevent me from doing that.

Does anyone know what other array-oriented languages use? I know what
MATLAB does:

>> exp(-777)
ans =
     0
>> exp(777)
ans =
   Inf
>> sqrt(-1)
ans =
        0 + 1.0000i

Hey! I like that! Python is dynamic, why can't we just get the actual
answer to sqrt(-1), without using cmath, that always returns a complex ?
sorry, other subjet, not meant to be raised at the moment.

>> 54/0
Warning: Divide by zero.
ans =
   Inf                   

Here we get a warning, but also a result that won't crash the
computation.

>> a = 0/0
Warning: Divide by zero.
a =
   NaN
>> b = a
b =
   NaN
>> a == b
ans =
     0            

So comparing two NaNs yields a false, as it should, and though Python
won't do it now, it could. One thing that a numerical routine should
NEVER do is give an incorrect answer. No answer is often bad, but an
incorrect one is much worse. NaN == NaN must return false.

Does anyone know what FORTRAN 90 specifies (if anything)? What other
array-oriented languages are there?

I think what MATLAB does is what Tim is calling "bad *and* incomplete
754 support" Incomplete is surely true, "bad" is clearly a matter of
opinion. It seems we have a variety of users of numerics in Python, that
I break into three broad catagories:

Casual users:
mostly doing non-numeric stuff, with the occasional calculation:
This group could use any non-cryptic handling of over/underflow, it just
doesn't matter.

Mid-level number crunchers:
This is the group I put myself in. We crunch a lot of numbers, really
like the array semantics (and speed) of NumPy, and are doing things like
graphing functions, statistical calculations, etc. We have probably only
taken one of two (at most) numerical analysis courses, and many don't
know what the heck IEE 754 is. (The one Numerical Analysis course I did
take, happened to be with Kahan, which is why I know what it is)

For this group, the incomplete IEEE support is probably the best way to
go. We're more likely to be annoyed by our whole computation stopping
because of one bad data point, than we are to be pissed off that it
didn't stop when it started to compute garbage.

Hard Core Number crunchers:
These are the folks that do things like write optimised routines for
particular architectures, adn teach numerical analysis courses. These
folks want either FULL IEEE, or plain old "classic" overflow and
underflow errors, that they can handle themselves. Do these folks really
use Python as other than a glue language? Are they really doing massive
number crunching in Python itself, rather than in C (or whatever)
extensions? If so, I'd be surprised is they didn't find Huaiyu's
argument compelling when doing array based calculations.

Tim pointed out that Python was not designed with 754 in mind, so for
2.0, what he is doing is probably our best bet, but it seems to not be
the best ultimate solution, I hope using NaN and Inf will be considered
for future versions, even if it is incomplete 754 compliance.

Note: if the ultimate goal is REAL IEEE 754 compliance, is it possible
without custom re-compiling your own interpreter? If so, is there any
chance that it will come any time soon (2.1 ?) , so we don't have to
have this discussion at all?

Thanks for all of your work on this, Python just keeps getting better!!

-Chris

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