Hi Jason, On Wed, Dec 8, 2010 at 12:15 AM, Jason Grout <jason-s...@creativetrax.com> wrote: > I worry that it is too confusing to have a min_spanning_tree function in the > documentation of the spanning_tree module that is different than the > min_spanning_tree method of a graph (different interface, more checks, > etc.).
That is nothing compared to the case where we have implemented minimum spanning tree for digraphs in sage/graphs/digraph.py. Now when someone wants to maintain the minimum spanning tree code, the maintainer would be looking into at least two different modules, namely sage/graphs/graph.py and sage/graphs/digraph.py. If an issue affects both implementations of minimum spanning trees, i.e. those in the directed and undirected cases, what is the chance of someone fixing both implementations in the same patch? The idea of centralization is that there is one place where a maintainer would go to maintain the relevant code. Scattering code for essentially similar functionality across more than one file is a recipe for more work on future maintainers. NetworkX was designed as a library and many of its implementation of graph theoretic algorithms are not written as methods of graph classes, but rather as separate functions and organized in separate modules. To me this makes the job of maintenance easier. But let's move beyond that argument as I get the impression that it has failed so far to impress anyone, just as the argument of method bloat has failed. > How about an option 3: > > * directly import the spanning_tree.min_spanning_tree function into the > graph/digraph namespaces. > > That way, spanning_tree.min_spanning_tree(G) is exactly the same as > G.min_spanning_tree(). Here's an option that should preserve the current interface of min_spanning_tree() while also allowing one to discover that method via tab completion. Move min_spanning_tree() higher up the class hierarchy and into sage/graphs/generic_graph.py. Once moved there, leave the interface alone and proceed to clean-up that method as follows: * Handle the cases of digraphs, multigraphs, and multidigraphs. * Handle weighted and unweighted cases of the above graph types. Goodies like algorithms for randomized spanning tree constructions should go into another module like sage/graphs/trees.pyx. I feel this is really a time to declare a serious moratorium on adding new methods to any of the following modules, unless there is a good reason to do so: * sage/graphs/generic_graph.py * sage/graphs/graph.py * sage/graphs/digraph.py -- Regards Minh Van Nguyen -- 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
