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