generators of groups created with AbelianGroup

[ThomasBreuer]

The following looks rather confusing.
The generators of the groups generated by AbelianGroup do not always correspond to the prescribed exponents.

gap> AbelianGroup( [ 2, 3, 4 ] );
<pc group of size 24 with 3 generators>
gap> AbelianGroup( [ 1, 2, 3 ]);
<pc group of size 6 with 3 generators>
gap> AbelianGroup( [ 1, 2 ] );
<pc group of size 2 with 2 generators>
gap> AbelianGroup( [ 1 ] );
<pc group of size 1 with 0 generators>
gap> AbelianGroup( [ 1, 1 ] );
<pc group of size 1 with 0 generators>
gap> AbelianGroup( [ 1, 1, 2 ] );
<pc group of size 2 with 3 generators>

If one prescribes a result in IsPermGroup, the situation is different.

gap> AbelianGroup(IsPermGroup, [ 1, 1 ] );
Group(())
gap> AbelianGroup(IsPermGroup, [ 1, 2 ] );
Group([ (), (1,2) ])
gap> AbelianGroup(IsPermGroup, [ 1 ] );
Group(())
gap> AbelianGroup(IsPermGroup, [ 1, 1, 1 ] );
Group(())

And an empty list of exponents works for IsPcGroup (which is the default) but is not allowed for IsPermGroup and IsFpGroup.

gap> AbelianGroup( [] );
<pc group of size 1 with 0 generators>
gap> AbelianGroup( IsPcGroup, [] );
<pc group of size 1 with 0 generators>
gap> AbelianGroup( IsPermGroup, [] );
Error, <arg> must be nonempty
[...]
gap> AbelianGroup( IsFpGroup, [] );
Error, <ints> must be a list of integers
[...]

It would be helpful if we could rely on a correspondence of the generators with the given exponents. The statement in the documentation

The generators of the group returned are the elements corresponding to the factors Cints[i] and hence the integers in ints.

can be understood as the promise that this should hold.

[hulpke]

Is there a reason to allow generator order 1 (beyond "it can be considered valid input")?
Reason might simply be not to use GroupWithGenerators.

[ThomasBreuer]

@hulpke I would argue that if someone asks for an abelian group with generators of prescribed orders then GAP should produce a group with these generators. The current behaviour is just inconsistent (and inconsistent with the manual), some generators of order 1 are created, some are not.

[hulpke]

@ThomasBreuer One way to resolve the inconsistency is to trigger an error if orders of 1 are given as argument

[ThomasBreuer]

If we forbid 1 as an entry in the list given to AbelianGroup then this must be done consistently, and the documentation must be changed. I would regard this as a breaking change.

Note that in this setup entering an empty list would be the only way to ask AbelianGroup for a trivial permutation group, and this syntax is currently not allowed.
Whereever code uses AbelianGroup programmatically, it must contain a special handling of trivial groups, and this will break as soon as generators of order 1 are not allowed anymore.