[Numpy-discussion] slow numpy.clip ?

Travis Oliphant oliphant at ee.byu.edu
Tue Dec 19 19:21:31 CST 2006

Robert Kern wrote:
> David Cournapeau wrote:
>> Basically, at least from those figures, both versions are pretty 
>> similar, and not worth improving much anyway for matplotlib. There is 
>> something funny with numpy version, though.
> 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))

There are a lot of functions that are essentially this.   Many things 
were done to just get something working.  It would seem like a good idea 
to re-code many of these to speed them up.
> 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.
The problem with the copy=True keyword is that it would imply needing to 
expand the C-API for PyArray_Clip and should not be done until 1.1 IMHO.

We would probably be better off not expanding the keyword arguments to 
methods as well until that time.


More information about the Numpy-discussion mailing list