[Numpy-discussion] Toward release 1.0 of NumPy

[Tim Hochberg]

Travis Oliphant wrote:

> Travis Oliphant wrote:
>
>>
>> The next release of NumPy will be 0.9.8
>>
>> Before this release is made,  I want to make sure the following 
>> tickets are implemented
>>
>> http://projects.scipy.org/scipy/numpy/ticket/54
>> http://projects.scipy.org/scipy/numpy/ticket/55
>> http://projects.scipy.org/scipy/numpy/ticket/56
>
>
>
> So you don't have to read each one individually:
>
>
> #54 :  implement thread-based error-handling modes
> #55 :  finish scalar-math implementation which recognizes same 
> error-handling
> #56 :  implement rich_comparisons on string arrays and unicode arrays.


I'll help with #54 at least, since I was the complainer, er I mean, 
since I brought that one up. It's probably better to get that started 
before #55 anyway. The open issues that I see connected to this are:

    1. Better support for catching integer divide by zero. That doesn't 
work at all here, I'm guessing because my optimizer is too smart. I 
spent a half hour this morning trying how to set the divide by zero flag 
directly using VC7, but I couldn't find anything. I suppose I could see 
if there's some pragma to turn off optimization around that one 
function. However, I'm interested in what you think of stuffing the 
integer divide by zero information directly into a flag on the thread 
local object and then checking it on the way out. This is cleaner in 
that it doesn't rely on platform specific flag setting ifdeffery and it 
allows us to consider issue #2.

    2. Breaking integer divide by zero out from floating point divide by 
zero. The former is more serious in that it's silent. The latter returns 
INF, so you can see that something happened by examing your results, 
while the former returns zero. That has much more potential for 
confusion and silents bugs. Thus, it seems reasonable to be able to set 
the error handling different for integer divide by zero and floating 
point divide by zero. Note that this would allow integer divide by zero 
to be set to 'raise' and still run all the FP ops at max speed, since 
the flag saying do no error checking could ignore the int_divide_by_zero 
setting.

   3. Tossing out the overflow checking on integer operations. It's 
incomplete anyway and it slows things down. I don't really expect my 
integer operations to be overflow checked, and personally I think that 
incomplete checking is worse than no checking. I think we should at 
least disable the support for the time being and possibly revisit this 
latter when we have time to do a complete job and if it seems necessary.

   4. Different defaults I'd like to enable different defaults without 
slowing things down in the really super fast case.


Looking at this list now, it looks like only #4 needs to be addressed 
when doing the initial implementaion of the thread local error handling 
and even that one can be done in parallel, so I guess we should just 
start with creating the thread local object and see what happens. If you 
like I can start working on this, although I may not be able to get much 
done on  it till Monday.

Regards,

-tim