[Numpy-discussion] Toward release 1.0 of NumPy

[Travis Oliphant]

Tim Hochberg wrote:

> 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:

Great.  I agree that #54 needs to be done before #55 (error handling is 
what's been holding up #55 the whole time.

>
>    1. Better support for catching integer divide by zero. That doesn't 
> work at all here,

Probably a platform/compiler issue.   The numarray equivalent code had 
an if statement to prevent the compiler from optimizing it away.  
Perhaps we need to do something like that.   Also, perhaps VC7 has some 
means to set the divide by zero error more directly and we can just use 
that.

> 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. 


Hmm..   The only issue is that dictionary look-ups are more expensive 
then register look-ups.    This could be costly.


> 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.


Interesting proposal.    Yes, it is true that integer division returning 
zero is less well-justified.   But, I'm still concerned with doing a 
dictionary lookup for every divide-by-zero, and (more importantly) to 
check to see if a divide-by-zero has occurred.   The dictionary lookups 
is the largest source of small-array slow-down when comparing Numeric to 
NumPy.

>
>   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.

I'm all for that.   I think it makes the code slower and because it is 
incomplete (addition and subtraction don't do it), it makes for 
harder-to-explain code.

On the scalar operations, we should check for over-flow, however...

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


The discussion on different defaults is fine.   The slow-down is that 
with the current defaults, the error register flags are not actually 
checked if the default has not been changed.    With the 
numarray-defaults, the register flags would be checked at the end of 
each 1-d loop.   I'm not sure what kind of slow-down that would bring.   
Certainly for 1-d cases, there would be little difference.

One could actually simply store different defaults (but it would result 
in minor slow-downs because the register flags would be checked.

-Travis