Convergence of algorithms.graph with networkx

[bthirion]

A common/similar API

The algorithms.graph library is quite comparable to the specification of a nx.DiGraph object, with some restrictions, plus some nx algorithms. The function-based structure of nx is interesting and could be used as a model for the graph library. For some algorithms at least, there does not seem to be a large difference in terms of performance.

dependency

The question of whether nx could become a dependence of nipy is open, but I believe one should reduce rather than increase the dependences of nipy.

the field object

In nipy.algorithms.graph.field, we define the Field class, which is a graph, with an array of features, written as (nodes, dimension) array: each node has its own feature. This allows the implementation of mrophological mathematics operation (dilation, erosion, watershed, local maxima) or diffusion processes on these values. Networks allows the definition of node attributed, and is actually incredibly flexible in that respect, but I haven't seen any equivalent of the morphological operations that we had with Field methods.

efficiency

We've lost quite a lot of efficiency when shifting from c to py. Some of it might be recovered by using more cython.

[matthew-brett]

Thanks for this very useful summary.

It's not urgent, but it worth bearing in mind the cost of having our own code to do the same thing as networkx. First it makes our own code larger and more complicated and puts a maintenance burden on us, that could be shared with the larger pool of networkx users. Second, it means that we lose the opportunity to contribute new and useful algorithms to the larger community of graphers. We then don't get the useful design discussions, testing and maintenance that we might if contributing to the more general library. On the the other hand, the cost of the dependency is rather small, because we go from recommending this:

easy_install sympy
easy_install nibabel

to this:

easy_install sympy
easy_install nibabel
easy_install networkx

networkx is already a dependency for nipype, and an optional dependency for nitime.

[bthirion]

It's not urgent, but it worth bearing in mind the cost of having our own code to do the same thing as networkx. First it makes our own code larger and more complicated and puts a maintenance burden on us, that could be shared with the larger pool of networkx users. Second, it means that we lose the opportunity to contribute new and useful algorithms to the larger community of graphers. We then don't get the useful design discussions, testing and maintenance that we might if contributing to the more general library. On the the other hand, the cost of the dependency is rather small, because we go from recommending this:

 easy_install sympy
 easy_install nibabel

to this:

 easy_install sympy
 easy_install nibabel
 easy_install networkx

networkx is already a dependency for nipype, and an optional dependency for nitime. I agree that having our own code for graph operations comes at a cost, and that using nx instead looks like a good idea (I had not carefully looked at it so far).

Comment on dependencies: I am in favor of removing sympy (and adding scikit-learn).

1. I'm not sure at all that sympy is really important, in the sense
   that it does not really seem to make the code clearer or cleaner. This may not be the right place to have this debate. Anyway, I'm thinking of rewriting the design matrix stuff without sympy. Is there any place in the codebase where it is really a plus ?
2. On the other hand, if we take scikit learn as a dependency, we'll be able to remove some non neuroimaging-specific code, and propose new features. Please let me know if I'm wrong.

[matthew-brett]

Jonathan's formula code uses sympy; are you proposing removing or rewriting that? If so - please mail the list with the suggestion.

Similarly for scikits-learn - please email the list with the suggestion - or - if it is easy - make a pull request with the changes.