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

Reply via email to