[Numpy-discussion] Fwd: [numpy] ENH: Initial implementation of a 'neighbor' calculation (#303)

Sebastian Berg sebastian at sipsolutions.net
Thu Oct 11 08:40:16 EDT 2012


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 at 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 at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion





More information about the NumPy-Discussion mailing list