Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)

[Kevin Jacobs]

Huaiyu Zhu <huaiyu_zhu at yahoo.com> wrote:
> [Guido van Rossum]
>> No, the configure patch is right.  Tim will check in a change that
>> treats ERANGE with a return value of 0.0 as underflow (returning 0.0,
>> not raising OverflowError).

> What is the reason to do this?  It looks like intetionally subverting ieee
> even when it is available.  I thought Tim meant that only logistical
> problems prevent using ieee.

> If you do choose this route, please please please ignore ERANGE entirely,
> whether return value is zero or not.

> The only possible way that ERANGE could be useful at all is if it could be
> set independently for each element of an array, and if it behave as a
> warning instead of an exception, ie.  the calculation would continue if it
> is not caught.  Well, then, Inf and NaN serve this purpose perfectly.

> It is very reasonable to set errno in glibc for this; it is completely
> unreasonable to raise an exception in Python, because exceptions cannot be
> set to individual elements and they cannot be ignored.

My $2.0e-2:  Huaiyu is absolutely right on this one.  Python is fighting
IEEE 754 tooth and nail, effectively preventing it from ever working.  While
the changes necessary to fix this in general may be too dramatic for 2.0, it
is an inevitable that it will have to be done.  There is simply too much
need for it and virtually no reason not to.  The devil is in the details, as
always.  Here is a micro plan for workable IEEE754 support:

1)  Detect if a platform supports IEEE arithmetic and traps.

2a) If so, compile/link with the options to enable it and use a default set
    of traps so that non-scientific/numerical users have sane behavior. 
    This seems to be defined as always trapping overflow and division by
    zero.  Provide a default SIGFPE handler that translates IEEE traps into
    Python arithmetic exceptions.

2b) Provide a simple interface to set and query FPU control flags.  This
    includes rounding modes, and traps.  Define functions to get NaN, Inf
    and test fp class.

3a) If the system is not IEEE 754-ready, provide virtually the same
    emulation currently provided.  Implement the same FPU control interface,
    but raise an exception if the option isn't available (i.e. rounding mode
    control).  The easiest thing to emulate are traps.

    E.g, use the current set of errno checks augmented with pseudo-IEEE 754
    flags.

    if( errno == ERANGE && fpu_control.trap_underflow ) {
      // raise exception
    }

And yes, I am volunteering to help out with the implementation.  After some
discussion, I'll start work on a PEP.

-Kevin
    
-- 
----------->  Kevin Jacobs  <-----------|------->  (216) 778-8211  <--------
Informatics Consultant                  | Department of Epidemiology
Primary mail:   jacobs at theopalgroup.com |   & Biostatistics
Alternate mail: jacobs at darwin.cwru.edu  | Case Western Reserve University
----------------------------------------------------------------------------