[Numpy-discussion] slow numpy.clip ?

[Travis Oliphant]

David Cournapeau wrote:
> Robert Kern wrote:
>   
>> Looking at the code, it's certainly not surprising that the current
>> implementation of clip() is slow. It is a direct numpy C API translation of the
>> following (taken from numarray, but it is the same in Numeric):
>>
>>
>> def clip(m, m_min, m_max):
>>     """clip()  returns a new array with every entry in m that is less than m_min
>>     replaced by m_min, and every entry greater than m_max replaced by m_max.
>>     """
>>     selector = ufunc.less(m, m_min)+2*ufunc.greater(m, m_max)
>>     return choose(selector, (m, m_min, m_max))
>>
>>
>> Creating that integer selector array is probably the most expensive part.
>> Copying the array, then using putmask() or similar is certainly a better
>> approach, and I can see no drawbacks to it.
>>
>> If anyone is up to translating their faster clip() into C, I'm more than happy
>> to check it in. I might also entertain adding a copy=True keyword argument, but
>> I'm not entirely certain we should be expanding the API during the 1.0.x series.
>>
>>     
> I  would be happy to code the function; for new code to be added to 
> numpy, is there another branch than the current one ? What is the 
> approach for a 1.1.x version of numpy ?
>   
The idea is to make a 1.0.x branch as soon as the trunk changes the C-API. 

The guarantee is that extension modules won't have to be rebuilt until 
1.1.  I don't know that we've specified if there will be *no* API 
changes.  For example, there have already been some backward-compatible 
extensions to the 1.0.X series. 

I like the idea of being able to add functions to the 1.0.X series but 
without breaking compatibility.  I also don't mind adding new keywords 
to functions (but not to C-API calls as that would require a re-compile 
of extension modules).


-Travis