[SciPy-Dev] Refactoring ndimage

[Jaime Fernández del Río]

Hi all,

I have started sending PRs for ndimage. It is my intention to keep at it
through the summer, and would like to provide some context on what I am
trying to achieve.

A couple of years ago I mentored a GSoC to port ndimage to Cython that
didn't do much progress. If nothing else, I think I did learn quite a bit
about ndimage and what makes it hard to maintain. And I think one of the
big ones is lack of encapsulation in the C code: ndimage defines four
"classes" in ni_support.h
<https://github.com/scipy/scipy/blob/master/scipy/ndimage/src/ni_support.h>
that
get used throughout, namely NI_Iterator, NI_LineBuffer, NI_FilterIterator
and NI_CoordinateList.

Unfortunately they are not very self contained, and e.g. to instantiate a
NI_FilterIterator you typically have to:

   - declare a NI_FilterIterator variable,
   - declare two NI_Iterator variables, one for the input array, another
   for the output,
   - declare a npy_intp pointer of offsets and assign NULL to it,
   - call NI_InitFilterOffsets to initialize the offsets pointer,
   - call NI_InitFilterIterator to initialize the filter iterator,
   - call NI_InitPointIterator twice, once for the input, another for the
   output,
   - after each iteration call NI_FILTER_NEXT2 to advance all three
   iterators,
   - after iteration is finished, call free on the pointer of offsets.

There is no good reason why we couldn't refactor this to being more like:

   - call NI_FilterIterator_New and assign its return to a
   NI_FilterIterator pointer,
   - after each iteration call NI_FilterIterator_Next to advance all
   involved pointers,
   - after iteration is finished, call NI_FilterIterator_Delete to release
   any memory.

Proper encapsulation would have many benefits:

   - high level functions would not be cluttered with boilerplate, and
   would be easier to understand and follow,
   - chances for memory leaks and the like would be minimized,
   - we could wrap those "classes" in Python and test them thoroughly,
   - it would make the transition to Cython for the higher level functions,
   much simpler.

As an example, the lowest hanging fruit in this would be #7527
<https://github.com/scipy/scipy/pull/7527>.

So open source wise this is what I would like to spend my summer on. Any
feedback is welcome, but I would especially like to hear about:

   - thoughts on the overall plan,
   - reviewer availability: I would like to make this as incremental as
   possible, but that means many smaller interdependent PRs, which require
   reviewer availability,
   - if anyone wants to join in the fun, I'm more than happy to mentor!

Jaime

-- 
(\__/)
( O.o)
( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
de dominación mundial.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20170625/bffb4cad/attachment.html>