Inconsistent generating sets

[markuspf]

This was reported by @laurentbartholdi in #1238

There's another bug, or at least annoyance, in that trivial permutation groups sometimes have 0 generators and sometimes 1:

gap> g := TrivialGroup(IsPermGroup);
Group(())
gap> GeneratorsOfGroup(g);
[ () ]
gap> TrivialSubgroup(g);;
Group(())
gap> GeneratorsOfGroup(last);
[ ]

Note that ViewString always prints the identity () as a generator, but String does not.

[markuspf]

I don't know where the function GeneratingSet comes from, it is not present in my current GAP installation. I can use GeneratorsOfGroup though.

I don't think the first issue is a bug per-se. If you call Group(()), GAP creates a permutation group with the generating set [ () ], and we make no attempt at making that generating set smaller. TrivialSubgroup creates a subgroup of G with no generators.

The point being that with a subgroup of a group we can still deduce what kind of generators this subgroup has none of.

[ChrisJefferson]

These kinds of "groups with no generators" also come out all the time in intersection problems:

gap> GeneratorsOfGroup(Intersection(Group((1,2)), Group((2,3)) ) );
[  ]

I do find them annoying, because Group(GeneratorsOfGroup(X)) doesn't work in general, and it would be nice if it did.

[fingolfin]

We could certainly change TrivialGroup(IsPermGroup) to return a permutation group with zero generators:

diff --git a/grp/basicprm.gi b/grp/basicprm.gi
index ffe1790d7..c9a075a86 100644
--- a/grp/basicprm.gi
+++ b/grp/basicprm.gi
@@ -18,7 +18,7 @@ InstallMethod( TrivialGroupCons,
     "perm group",
     [ IsPermGroup and IsFinite ],
     function( filter )
-    filter:= Group( () );
+    filter:= GroupByGenerators( [], () );
     SetIsTrivial( filter, true );
     return filter;
     end );

Note that dealing with groups with zero generators indeed has caused troubles several times in the past, because code as not expecting it -- but despite that, I think it's fine to return an empty generating set for trivial groups: In virtually all cases, adding support for trivial group was easy (and the empty set often lead to runtime errors, which I prefer over code silently failing, which easily happens when there is a single trivial generator)...

[hulpke]

@ChrisJefferson
That is exactly why Group allows a second parameter, which is the appropriate one, that is
Group(GeneratorsOfGroup(X),())
will always work.

[laurentbartholdi]

@markuspf sorry, please read "GeneratorsOfGroup".

@fingolfin I think indeed that the code should be written in such a way that it always accepts 0-generated objects, and it's more consistent that trivial groups always have 0 generators.

I believe @ChrisJefferson's argument about intersections is actually in favour of making sure that 0-generated groups are properly handled everywhere, better to fix the other places than to artificially add the trivial element as generator of the intersection. (John Conway calls wanting to avoid this "zerophobia").

[fingolfin]

With PR #1247, one gets

gap> g:=TrivialGroup(IsPermGroup);
Group(())
gap> GeneratorsOfGroup(g);
[  ]

[laurentbartholdi]

Great! Though, wouldn't it be even better to also change the printing routines to show Group() and Group([],()) respectively?

[markuspf]

Print should never print Group() as that is not valid GAP code (well, not code that can be used to recreate the printed object)

[laurentbartholdi]

Definitely! I meant Group() for ViewString and Group ([],()) for String and DisplayString, so as to recreate at object with 0 generators.

[hulpke]

Of course it could still happen in other calculations to end up with a trivial group that has (possibly multiple) generators, so any code needs to be more careful.

[fingolfin]

The original "issue" (?) reported here was resolved some time ago. This leaves the suggestion for printing, which I now put into a fresh issue, so that it is not forgotten, see #2036