Hi everyone,

I'm trying to design an interface for an nD "get_neighbors(idxs, ar, conn)" function: given one or more indices into an ndarray `ar`, and a connectivity (integer in {1, ..., ar.ndim}), return the indices of its neighbors. There's multiple design decisions to be made:

1. Work with linearized or regular indices? In the past I've used linearized indices because they are much easier to treat generally in an nd setting. However, most users probably don't want to deal with converting to and from linear indices (though np has a function to convert to and from linear indices). Perhaps more relevant though, linear indices get very very tricky once you stop dealing with contiguous arrays. In fact, I'm not quite sure I'm up to the task. ;)

2. If we want to work with regular indices, what should be the input format? There's lots of options: a list of tuples? a tuple of np.arrays of ints, similar to what numpy expects for __getitem__? a 2D array of ints, similar to the "coords" format used throughout ndimage?

3. What should the return format be? The problem is that edge pixels have fewer neighbors than non-edge ones. So, anything like a 2D ndarray is pretty much out of the question, *unless* we also return a matching array called something like `valid` that shows directions where the neighbor-finding has hit an edge. This is of course all sidestepped if we only allow one index to be passed, but that forgoes a lot of possible saved efficiency by not making lots of python function calls.

In the past, I've sidestepped the whole issue of the boundaries by padding my array and never asking for the neighbors of something in the "pad" area, but I don't think that's viable for a public-facing function. =)

I'll be very interested to hear what everyone has to say about this...! Thanks!

Juan.