> advantages are obvious, e.g. one will be able to get, say, all the
> known to DB regular graphs on 15 vertices of degree 6 and diameter
> 2...
> That's a standard DB query then. Now one would have to browse the
> source to answer this, it seems...
Well, my question about a large number of method
On Nov 29, 10:54 am, Dima Pasechnik wrote:
> > P.S. (if anybody has any smart idea about how to deal with classes
> > having *far too many* different methods, I am also very interested.
> > Something will have to be decided soon for the Graph class anyway...
> > :-/ )
>
> not that my reply quali
> P.S. (if anybody has any smart idea about how to deal with classes
> having *far too many* different methods, I am also very interested.
> Something will have to be decided soon for the Graph class anyway...
> :-/ )
not that my reply qualifies as very smart, but IMHO it's high time
Sage has a dat
I have thought for some time that it would be an improvement to have
groups. work in much the same manner as graphs. and to
have some of the less generally-useful groups moved out of the global
namespace (after a proper deprecation of that behavior).
And Dima's point (as on #9136) about buildin
see my comment on trac #9136 for a complete example.
On Nov 24, 11:17 pm, Dima Pasechnik wrote:
> Are you reinventing the wheel? :-)
>
> One should be able to import into Sage any graph that GAP can make
> using its package Grape. Grape is essentially doing what you seem to
> be doing: takes a pe
Are you reinventing the wheel? :-)
One should be able to import into Sage any graph that GAP can make
using its package Grape. Grape is essentially doing what you seem to
be doing: takes a permutation group and constructs a graph invariant
under it.
E.g.
gap> LoadPackage("grape");
gap> G:=NullGrap
