On Wed, 2012-10-10 at 12:55 -0400, Cera, Tim wrote:

On Wed, Oct 10, 2012 at 1:58 AM, Travis E. Oliphant notifications@github.com wrote: I'm not sure what to make of no comments on this PR. This seems like a useful addition. @timcera are you still interested in having this PR merged?

<snip>

Internally I implemented something like rolling window, but I don't return the windows. Instead the contents of the windows are used for calculation of each windows 'central' cell in the results array.

Rolling window can help with everything but the I guess typical case of neighbor(..., mode='same', pad=None), where the idea must fail since not all neighborhoods are the same size. It is probably quite a bit faster to replace the shapeintersect with it in those cases, but not sure if it is worth it. What I personally do not quite like is that for the case of the function being a ufunc, it not being (..., mode='same', pad=None) and weights=np.ones(...), the rolling window approach will be much faster as it can be fully vectorized with the new numpy versions. But thats just me and the documentation would have a "see also", so I guess users should be able to figure that out if they need the speed. Plus I don't see an elegant way to find the neighborhoods for (mode='same', pad=None) so having a function to help with it should be nice. On a general note, maybe it would make sense to allow a binary mask instead of the np.isfinite check and would it be better if the returned arrays are not raveled unless there is this mask? Also there is a ** missing for the kwargs in the function call.

After seeing the rolling window function I thought it might be nice to bring that out into a callable function, so that similar functionality would be available. That particular function isn't useful to me directly, but perhaps others?

Kindest regards, Tim _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion