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. -Travis _______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
