I think you can accomplish all these goals without "unbloating"
graphs. I think Sage users have gotten used to (please feel free to
correct me on this, Sage users!) looking for a method via tab
completion. I worry about how many features we have for graphs already
which I have seen users surprised to find. Cleaning up documentation
might make more people more aware of what Sage can do, but I think
moving these methods (at least in name) out of the graph classes would
be a push in the other direction.
--
Robert L. Miller
http://www.rlmiller.org/
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.). 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().
Thanks,
Jason
-1 on moratoriums. Adding restrictions for restriction sake is
foolish. Yes, these files are too large. Yes, splitting off certain
functionality will make them smaller. However, if someone implements a
function which starts off a new area of graph theory, and they don't
know where else to put it, it seems perfectly reasonable to put it in
here. Especially if this is someone we're trying to rope in to more
serious development. Later on when there are more functions, and it
makes sense to split these off into a new file, that's a good idea and
a good time to do it.
>
> --
> Regards
> Minh Van Nguyen
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
Would there be any way to ask Sphinx to produce one page per method
instead of having them all on one page ? Having such a long page
containing all our methods means that it is impossible, from Google,
to find the description of a method containing at once a list of
keywords... In its actual state, Google will often give this page as
an answer to any request containing "reference sage graph" and
anything else, because most of the terms are probably scattered
through it. If there was a way to have instead a "list of methods
contained in graph.py", then a link toward a page describing each of
them, it would finally become possible to isolate functions of
interest through Google.
"I'll be back"
Nathann
I think maybe I was too brief in my suggestion to be clear. I would
favor refactoring the code out to a spanning_tree.py(x) file. My point
was that your propositions seemed to indicate that the graph class
methods that would call spanning_tree.min_spanning_tree would also do
some additional error checking, maybe have a different interface, etc.
My suggestion was to not have any additional code; put all of that error
checking, etc., into the spanning_tree.min_spanning_tree function. In
other words, the graph class would simply import the functions into the
class namespace:
class Graph:
from spanning_tree import min_spanning_tree
That way we get a standalone function in
spanning_tree.min_spanning_tree, and we also get a convenient method for
all graphs, and they are exactly the same function, have the same
interface, etc. There is no duplication of code or of doctests.
Of course, this import should probably be moved up to the generic graph
class, like you suggest, if the function can handle digraphs too.
Thanks,
Jason
Yep. Basically, the method becomes a convenient alias to the function
in the spanning_tree module.
With this model, I can see one solution to the "method bloat". Common
algorithms/functions have aliases as methods. Extensions or uncommon
functions don't have aliases as graph class methods, but live in the
spanning_tree module. I'm not sure how I feel about it, but it is an
idea...
Jason
My question on sphinx-dev was finally answered : it sounds possible to
have one page per method ! :-)
http://groups.google.com/group/sphinx-dev/browse_thread/thread/41a2fc455ff98d6e?hl=en
Nathann
While I was struggling to make Sphinx run with the correct options,
Minh the Great was already building an example and creating a new
thread :-D
http://groups.google.com/group/sage-devel/browse_frm/thread/65c25bb4d2e94a45
Nathann