The usual convention in graph theory is that a Cayley graph does _not_ have to be connected. For example it is a basic theorem due to Sabidussi that a graph X is a Cayley graph for a group G if and only if G acts regularly on the vertices of X. Since there does not appear to be a significant cost in following this convention, I think it should be followed.
Chris Godsil On Jan 27, 5:28 pm, "Nicolas M. Thiery" <nicolas.thi...@u-psud.fr> wrote: > Hello, > > Let me advertise a patch on #8044 which introduces categories in the > group code and uses it to do some cleanup. There are some minor design > questions which I thought should be brought up here. This is a > followup to #7921, and I'd love to see it in 4.3.2. > > Thanks in advance for feedback and review! > > Cheers, > Nicolas > > Categories for finite/permutation/symmetric groups > > http://trac.sagemath.org/sage_trac/ticket/8044 > > Ticket description: > > * Introduces two new categories: FiniteGroups? and > FinitePermutationGroups? > > * Puts all permutation groups and some other finite groups in the > corresponding categories. There remains to handle finite matrix > groups and Galois groups in sage/rings/number_field/. > > * As a result, this standardizes the interface of those groups > (cardinality, one, ...). > > * Deprecates the class sage.groups.group.FiniteGroup. Content > moved to the SemiGroups / FiniteGroups categories > > * Merges cayley_graph with that for FiniteSemigroups. In the > merging, connecting_set was deprecated to generators. Also > providing a single element by itself as connecting set is no > more supported. Finally the default is side = "right" (was > "twosided" for semigroups). This method is also generalized to > Semigroups with an elements option (should this be vertices?). > > Why do we care about the produced graph using implementation = > "networkx"? I would tend to remove this implementation detail; > this would change the order of the edges, which requires fixing > a test in sage.graphs.generic_graphs > > * Provides group_generators defined from gens, as well as > semigroup_generators defined from group_generators in the finite > and coxeter cases. > > * Also puts the SymmetricGroup in the FiniteWeylGroups category. > Beware: unusual product convention > Beware: this changes the generators to the standard Weyl group > generators, that is the elementary transpositions > > * Adds an has_descent method to permutation group elements > > * Make all named permutation groups have UniqueRepresentation > > * Questionable: the underlying set of an alternating or symmetric > group is now a tuple. This is safer and helps > UniqueRepresentation. However, this could break backward > compatibility. Also, maybe we want to keep the output as > SymmetricGroup([1,3,4])? > > * Makes more systematic use of TestSuite(...).run() > > * Makes a minor improvement to FiniteEnumeratedSets tests for > large finite enumerated sets > > * Strips away unused imports > > * Updates a couple doctests here and there > > Nicolas > -- > Nicolas M. Thi ry "Isil" <nthi...@users.sf.net>http://Nicolas.Thiery.name/ -- 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