GSoC: Rewriting scipy.ndimage in Cython

[Ralf Gommers]

On Wed, Mar 25, 2015 at 4:26 AM, Jaime Fernández del Río <
jaime.frio at gmail.com> wrote:

> On Tue, Mar 24, 2015 at 5:34 PM, AMAN singh <ug201310004 at iitj.ac.in>
> wrote:
>
>> Hi Everyone
>>
>> I have made a basic draft of my proposal here
>> <https://docs.google.com/document/d/1-dRqhFzyWnoDJl82KsYECo00B82osR6hujaZ008NUR8/edit?usp=sharing>
>> .
>> Please review it and suggest modifications.
>>
>
> Hi Aman,
>
> This may not be 100% true for all the functionality, but I believe that
> the gist of the ndimage module is in the 4-5 object-like constructs in
> ni_support, namely:
>
>
>    - NI_Iterator in its three flavors: point, subspace and line iterator,
>    - NI_LineBuffer and
>    - NI_FilterIterator.
>
> Closely linked to this is the choice of a method to deal with multiple
> dtypes, a question for which I don't think there is an obvious answer.
> Since performance is critical, you may want to take a look at bottleneck's
> use of templates that are pre-processed before cythonizing and compiling.
>
> If you get these right, then rather than the leaves of the tree, you will
> have built a solid foundation, more like the the trunk: porting all the
> other modules is then going to mostly be little more than an exercise in
> translation. So I would suggest that you devote more time to getting these
> fundamental questions right, as some trial and error is going to be
> inevitable.
>

This sounds like great advice.

Comments on the timeline:
- week 1 "reading through the code": I think you should cover, and will
have covered this, in the communitiy bonding period. At the start of week 1
you should be at the point where you start tacking the problem. Probably by
doing what Jaime says above.

- unit tests, docs and benchmarks: these cannot be separated from writing
code. Each PR should have decent unit test coverage and a decent docstring.
Plus since performance is critical you have to benchmark your code as you
go. The only thing you could reserve time for at the end is writing some
longer documentation (maybe a tutorial), benchmarks in ASV format (see
https://github.com/scipy/scipy/tree/master/benchmarks) and some minor
cleanups.

Regarding "I will also use better algorithms when possible to improve the
time complexity of the functions": it is important to not mix porting code
from C to Cython with changing the algorithm, because when output of a
function doesn't match the current Scipy output you don't know whether
porting or algorithm changes are the cause.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20150325/19e3a15d/attachment.html>