On Mon, Jan 11, 2010 at 10:49:55AM -0800, Nick Alexander wrote:
I think I agree with this last sentiment. Why not have a
SetOfCliquesOfGraph object returned by G.cliques(), which is then
further interrogated? Ie, cliques = G.cliques();
cliques.max_clique(), etc. This worked well with
Nathann Cohen wrote:
The thing is that we have at the moment something like 210 functions
in the Graph class. We can not really keep on adding the new ones
without caring about what it is becoming.
In response, Robert Bradshaw wrote:
Why is that too many? I like being able to type g.tab and
Why is that too many? I like being able to type g.tab and see every
single
method that is available. If one is interested in trees,
g.treetab[tab]
gives a smaller subset. Or read the documentation.
I'm +.9 on this, because I do have one caveat: most of the sage
objects with half a million
Hello everybody !!! This is a copy of a mail I sent to Robert Miller,
who may require a larger audience :-)
---
I was thinking about the huge list of functions we have at the moment
in the Graph class, and the length of Graph.py.
Well, I am at the moment convinced ( if you are
On Jan 10, 2010, at 12:15 AM, Nathann Cohen wrote:
Hello everybody !!! This is a copy of a mail I sent to Robert Miller,
who may require a larger audience :-)
---
I was thinking about the huge list of functions we have at the moment
in the Graph class, and the length of
This won't work for methods, as the functions in clique won't get a bound
self. I.e. you'd have to write
sage: g.trees.is_tree(g)
unless you did some trickery behind the scenes.
Yes, I thought we could replace g.is_trees by g.trees.is_tree
I would actually find this interface less easy to
