#14536: Random tournaments, a misnamed method and a segfault
---------------------------------+------------------------------------------
Reporter: ncohen | Owner: jason, ncohen, rlm
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-5.10
Component: graph theory | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers:
Authors: Nathann Cohen | Merged in:
Dependencies: #14475 | Stopgaps:
---------------------------------+------------------------------------------
Comment (by ncohen):
Hellooooooo !!
> - Why not displaying anymore the number of vertices in the name method
of TransitiveTournament? Since other graphs do the same that would be
consistent.
Well. This is the result with the patch as it is :
{{{
sage: digraphs.TransitiveTournament(5)
Transitive Tournament: Digraph on 5 vertices
}}}
If the number of vertices is included in the name, you get "Transitive
Tournament on 5 vertices: Digraph on 5 vertices".
> - A potential alternative name would be "chain"
For what ? Transitive tournament ? `O_o`
Hey, it's not a Poset ! It's a digraph ! `:-P`
Plus it would really make people think of this :
{{{
sage: digraphs.Path(5)
Path on 5 vertices: Digraph on 5 vertices
}}}
Oh, by the way the name contains the number of vertices in this case. What
do you think ?
> - In the tournament generator using Nauty, once the nauty command is
constructed, it seems that all the rest is generic (calling Nauty, parsing
the output, building and yielding the graphs). What about extracting this
into a generic function?
HMmmmmm. Most of it is, yes. Building the string that Nauty received as
input is not, and parsing the graph is not either.. Usually Nauty returns
a sparse6_string but Sage does not understand sparse6 string for digraphs
yet. And there was a small difference in #14474 too.
Well, you are right a large part of it could be made automatic. It would
also be the occasion to create a Nauty module, and so a documentation page
about the Nauty spkg (how it is to be installed, which Demigod first wrote
it.
Let's say another patch ? We still do not have the interface from Sage to
Nauty's digraph generation. It's not that bad because we have Robert
Miller's version in Sage, but I will probably do it someday. So I'll do
both then `:-)`
> In the long run, it would be nice to have a uniform interface for
generating graphs using either Sage's engine or nauty (say with an
algo=nauty/Sage optional switch, which would default to Sage, unless nauty
become a standard package some
Nauty is not a part of Sage because of license problems... And it knows
how to enumerate things that are not implemented in Sage yet (like
hypergraphs `:-PPP`).
It goes in both directions, though. It is easy to enumerate through Sage
the list of graphs satisfying some specific property, and the property is
actually tested *during* the enumeration. No way to do this with Nauty,
unless we *REALLY* rewrite the interface and call Nauty's C functions
directly `:-P`
Nathann
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14536#comment:3>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
