Add is_cayley_graph

[jaanos]

This ticket adds a method is_cayley to GenericGraph. This method checks whether a graph or digraph (which may or may not be connected) is a Cayley graph. If requested, it also returns a permutation group, a mapping from vertices to group elements, and a generating set of the Cayley graph.

A method has_regular_subgroup has also been added to PermutationGroup_generic. It determines whether the group has a regular subgroup, and returns it if requested.

CC: @nathanncohen @dimpase

Component: graph theory

Keywords: Cayley graphs groups

Author: Janoš Vidali

Branch: c6680e7

Reviewer: Nathann Cohen

Issue created by migration from https://trac.sagemath.org/ticket/19586

[jaanos]

comment:84

Replying to @dimpase:

it is certainly true that you can assume w=1. So you have the neighbours of 1 in the graph (with its vertices labelled by the elements of G) say g₁,...,g_k. Now you need an argument that g₁,...,g_k generate G. I don't see it in what you wrote above.

If the graph is connected, they clearly do (if the graph is directed, vertex-transitivity then implies that it is also strongly connected). But they don't need to generate the group in the general case - it suffices that we get an isomorphic graph from the Cayley construction.

Janoš

[dimpase]

comment:85

Replying to @jaanos:

Replying to @dimpase:

it is certainly true that you can assume w=1. So you have the neighbours of 1 in the graph (with its vertices labelled by the elements of G) say g₁,...,g_k. Now you need an argument that g₁,...,g_k generate G. I don't see it in what you wrote above.

If the graph is connected, they clearly do (if the graph is directed, vertex-transitivity then implies that it is also strongly connected).

Ah, right. Sorry, I'm not very bright tonight. It's all good.

[6bdad4c1-1e26-4f2f-a442-a01a2292c181]

comment:86

Now, whether we allow Cayley graphs to be disconnected is just a matter of definition.

Hmmm... I'm sorry to switch this ticket back but I do not think that we should allow that. From what I know (which is very few) I also believe that your definition is better, but when there is a widespread definition of something then Sage must follow it. Corner-cases are okay when the definitions does not tell, but.. Well, what if people start counting those graphs, or filter only cayley graphs, and stuff?

I believe we should stick to the seemingly widespread definition and only allow connected ones.

It is particularly unpleasant because of the line from [comment:75]. Right now the .cayley_graph command outputs disconnected graphs, thus somebody will complain eventually that it does not always return cayley graphs >_<

Nathann

[jaanos]

comment:87

Hi!

Replying to @nathanncohen:

I believe we should stick to the seemingly widespread definition and only allow connected ones.

I see... but an easy solution to this would be to add an allow_disconnected parameter. Then the recursive call on the complement would set this to True - the original setting only matters for the initial graph, anyway.

What about non-simple graphs? I don't think the definitions say much about those, so we're probably good? Although the Wikipedia article linked above does say that a Cayley graph does not contain loops...

Janoš

[vbraun]

Changed branch from u/jaanos/add_is_cayley_graph to a58a734

[vbraun]

Changed commit from a58a734 to none

[jaanos]

Changed branch from a58a734 to u/jaanos/a58a7348bc022f39bf68383b70400e8b7f5b268b

[jaanos]

comment:91

Hi all!

I've added an allow_disconnected parameter. I hope it's OK this way.

By the way, is there any reason why the milestone has been changed to sage-7.2 when 7.1 has not been released yet?

Janoš

---

Last 10 new commits:

95dfa64	Add a doctest and some comments
4aaf301	Rename has_transitive_subgroup to transitive_subgroup and add helper function
382c0f2	Rename transitive_subgroup to regular_subgroup
8685628	Replace certificate with return_group, mapping and generators
95e34ee	Apply Nathann's suggestions
34f9212	Check for Cayleyness of the complement if the graph is simple with density > 1/2
d5b8bc7	trac #19586: Merged with 7.0
278bb47	trac #19586: Review
a58a734	Merge branch 'public/19586' into is_cayley_graph-gap
c6680e7	Do not consider disconnected graphs for Cayleyness unless explicitly requested

[jaanos]

Commit: c6680e7

[6bdad4c1-1e26-4f2f-a442-a01a2292c181]

comment:94

I've added an allow_disconnected parameter. I hope it's OK this way.

It's perfect this way! Thanks!

By the way, is there any reason why the milestone has been changed to sage-7.2 when 7.1 has not been released yet?

I don't think so. I set it back to what it was.

About loops, I wonder however. Is it still correct to look for a regular subgroup if there are loops?

Nathann

[6bdad4c1-1e26-4f2f-a442-a01a2292c181]

comment:95

P.S.: I used this code and the OEIS to count how many vertex-transitive graphs are not cayley graphs. The first counter-examples have cardinality 10, and there are exactly 2. Which is what this code found.

[jaanos]

comment:96

Hi!

About loops, I wonder however. Is it still correct to look for a regular subgroup if there are loops?

Why not? If there are any loops, there must be a loop on every vertex (otherwise the graph is not vertex-transitive and there is no regular subgroup). But then loops don't matter any more.

Janoš

[6bdad4c1-1e26-4f2f-a442-a01a2292c181]

comment:97

Would it be incorrect to imagine a graph in which the loops is not always due to the same generator? If the group is not regular.

Nathann

[jaanos]

comment:98

As vertices correspond to group elements, loops can only correspond to identity.

Janoš

[6bdad4c1-1e26-4f2f-a442-a01a2292c181]

comment:99

Sigh... Reading this group theory group will do me good.

Thank you very much for this branch, no other question, good to go :-P

Nathann

[vbraun]

comment:100

I set the milestone since you apparently need more time

[6bdad4c1-1e26-4f2f-a442-a01a2292c181]

comment:101

I'm sorry Volker... There was something I noticed just after changing the status....

Nathann

[vbraun]

Changed branch from u/jaanos/a58a7348bc022f39bf68383b70400e8b7f5b268b to c6680e7

[jaanos]

comment:103

Thanks everybody!

Janoš

[jaanos]

Changed commit from c6680e7 to none

[6bdad4c1-1e26-4f2f-a442-a01a2292c181]

comment:104

Ahahah. You did all the work, man!

[edd8e884-f507-429a-b577-5d554626c0fe]

comment:105

Very nice feature ! If gap_packages and database_gap are required (in the doc), how do the doctest pass without any # optional flag ?

[6bdad4c1-1e26-4f2f-a442-a01a2292c181]

comment:106

Probably because of the 'all' that appears in this piece of doc.

[jaanos]

comment:107

Indeed, GAP's ConjugacyClassesSubgroups works for some small groups (which include all groups in question in the doc) without any additional packages. However, TomLib and AtlasRep are required for a complete coverage.

Janoš

[edd8e884-f507-429a-b577-5d554626c0fe]

comment:108

Replying to @jaanos:

Indeed, GAP's ConjugacyClassesSubgroups works for some small groups (which include all groups in question in the doc) without any additional packages. However, TomLib and AtlasRep are required for a complete coverage.

I see. So, perhaps could some of the extra cases be tested as well since they use another (less tested) route.

[6bdad4c1-1e26-4f2f-a442-a01a2292c181]

comment:109

I see. So, perhaps could some of the extra cases be tested as well since they use another (less tested) route.

That would be testing GAP more than testing Sage. But well, no reason to stop you from doing so either I guess.