Add SubPcGroup type

[fingolfin]

... as discussed with @ThomasBreuer and @fieker . The plan is that PcGroup type is reserved for cases where the generators returned by gens form a pc sequence ("pcgs" in GAP lingo).

[fingolfin]

Some more notes:

1. the name SubPcGroup is preliminary
2. the documentation should spell out the relation between PcGroup and SubPcGroup, and also point out that one can convert to the former "as usual" (i.e. PcGroup(G) or isomorphism(PcGroup, G)
3. we also need a SubPcGroupElem type (very easy)
4. something similar should be done for FpGroup as well, i.e. adding a SubFpGroup type, see also problems with groups of type FPGroup #1836
5. given a SubPcGroup there should be a way to get the group it lives in; in GAP lingo that would be its "parent" but perhaps that'd be confusing given how parent is used so far in OSCAR? So here are some alternative names
   1. full_group
   2. whole_group
   3. ambient_group
6. this new type actually also simplifies some semantical issues we had with serialization support: if one serializes a vector of several SubPcGroup instances which all have the same "full group", then this property can now easily be preserved, because (de)serialization of a SubPcGroup would (de)serialize its "full group"
7. we must then adjust the code in _get_type resp. the vector _gap_group_types: currently it simply maps GAP.Globals.IsPcGroup to PcGroup which of course then isn't enough anymore.

[ThomasBreuer]

Some more aspects to be addressed by this change:

• PcGroup will then mean a group that knows/stores its polycyclic presentation, whereas a SubPcGroup group will initially not know such a presentation.
• Concerning PcGroup/SubPcGroup and FpGroup/SubFpGroup, one problem is that the latter corresponds to the distinction between IsFpGroup and IsSubgroupFpGroup in GAP (thus the different Julia types will correspond to different GAP filters), whereas the former has just IsPcGroup as corresponding GAP filter. There seems to be even no recommended way to decide in GAP whether a given IsPcGroup group is the full group or not. (Currently I would propose IsIdenticalObj( G, Parent( G ) ). Note that one cannot rely on GAP's Parent( G ) to point to the full group, the usual subgroup constructors such as DerivedSubgroup or SylowSubgroup set the given group as the parent of the result. Taking the last member of the chain of iterated Parents would perhaps make sense, but is not a good idea.)
• FpGroup(G::SubFpGroup) and PcGroup(G::SubPcGroup) will have to compute presentations for their arguments instead of just returning them. The same holds for isomorphism(::Type{FpGroup}, G:SubFpGroup) and isomorphism(::Type{PcGroup}, G:SubPcGroup).
• @fieker has argued that f.p. group functionality such as mapping words in terms of the generators or asking for the defining relators should be available also for pc groups. Once we have restricted the meaning of pc groups to full pc groups, this can be supported.
• The current documentation in Oscar seems to express already what this issue aims at.

[ThomasBreuer]

One item on the wishlist was that the generators of "full" pc groups and fp groups (which one gets by calling gens) satisfy the relations of the underlying presentation.

This property conflicts with the property of groups returned by abelian_group that the generators have the prescribed orders. Namely, if one asks for abelian_group(PcGroup, [1, 2, 3]) then the result has 3 generators, but the underlying presentation is built on 2 generators (because GAP does not support trivial steps in a pc series).

Does this perhaps indicate that it is not a good idea to assume a direct connection between gens and the underlying presentation?

[fieker]

Or it means that this case is not supported?

[ThomasBreuer]

Or it means that this case is not supported?

This would mean: The most important property for a full pc group G is that gens(G) satisfy the defining relations. Since the (GAP side of the) presentation does not allow for trivial steps in the polycyclic series, we cannot create abelian_group(PcGroup, orders) where some entries of orders are 1.

(Conversely, abelian_group(GrpAbFinGen, [1, 2, 3]) is not a problem because the relation matrix can deal with trivial entries.)

Shall we proceed like this?

[fingolfin]

In the particular case of abelian_group, of course one solution is to add generators which are trivial elements of the group; and to "precompute" the relations (we know them, of course: all generators commute, and x^ord(x)=1.

But the meta-question is: what kind of relations do we want to hold? One is that gens(G) and relators(G) should "fit together".

But are there others? E.g. if G is a pc-group do we promise that relators must return a pc-presentation? Or can it be any? (My personal view: we do not promise anything; if someone needs a pc-presentation, there should be a dedicated way to get that (and possibly in a "more structured" way than just a list of words that have to be untangled to e.g. extract relative order.

@fieker are there other properties you have in mind (e.g. for use in the cohomology code)?

[fingolfin]

@ThomasBreuer did you ever make any progress on implementing this?

Regarding doing something similar for fp groups, I now wonder if we perhaps also should have a separate type for free groups (and possibly their subgroups, though those at least really are free again, unlike with fp groups ...)

[fingolfin]

With #3166 merged we now have SubPcGroup. However, some bits and pieces are still missing (described at the top of that PR) which @ThomasBreuer would like to take care of before we close this (I think -- otherwise feel free to close this anytime, @ThomasBreuer )

[fingolfin]

@ThomasBreuer what is the status of this?

[ThomasBreuer]

The open items mentioned in #3166 are closed, this issue can be closed as well.