On Mon, Nov 30, 2009 at 9:01 PM, Robert Bradshaw <rober...@math.washington.edu> wrote: > I think the basic idea was that one could write a faster (sparse and > dense) graph "core," and then run all the NetworkX algorithms on top > of it as long as it supported the interface (for manipulating and > querying vertices and edges). If some code was still too slow then it > would be moved down to C (hopefully it would be sufficient to declare > the graphs as c-graphs and compile with Cython to remove all the > Python function call overhead). I don't know how well this works at > the moment. >
Is there any particular reason why this code couldn't be contributed upstream to Networkx? I use networkx outside of Sage, and it would be great to have speed improvements made there as well; since Sage already ships nx it would obviously benefit regardless. There may be a good reason for not doing so, I'm just curious. From my perspective, the more Sage work also benefits upstream projects, the more impact it has and more people benefit from it, both those who use Sage directly and those who may use those projects outside of Sage. Obviously in some cases this isn't viable (dependencies on core Sage code are an obvious one), hence my question. Cheers, f -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
