Add `closure_group`

[fingolfin]

A wrapper for GAP.Globals.ClosureGroup which takes a group and an element / list of elements / second group, all living in a common overgroup, and returns a new group generated by all those groups and elements.

So it would of course be trivial to wrap this but in OSCAR perhaps it should return more than just a closure group... Perhaps we should do the following?

• closure_group(G, x) for an element x returns the closure C and an embedding G -> H and also the image of x in C
• closure_group(G, [x,y,z]) for elements x, y, z returns almost the same but the last return value is a vector of the three images in C
• closure_group(G,H) could return the closure group C, and two embeddings G -> C and H -> C ?

Alas, this is potentially wasteful if we only need C and discard the other return values.

However, when the "image" of x is identical to x (typically if we are talking about PermGroup and PermGroupElem), then of course closure_group(G,x) can return x itself (which is "free") as final value. That leaves the morphism. That we could address if we had a TrivialGAPEmbeddingMorphism map type which could look like this:

# embedding of a GAP subgroup G into an overgroup H,
# where the images are just the identity
#
# pseudo code, needs adjustments
struct TrivialGAPEmbeddingMorphism{T <: GAPGroup} <: Map
  G::T
  H::T
end
domain(phi::TrivialGAPEmbeddingMorphism) = G
codomain(phi::TrivialGAPEmbeddingMorphism) = H

Then we could do something like this (optionally we can of course also verify that x is in the domain)

function image(phi::TrivialGAPEmbeddingMorphism{T}, x) where {T <: GAPGroup}
  @req x isa elem_type(T)
  #@req x in domain(phi) "argument is not in the domain"  # FIXME can be expensive 
  return x
end

Since this is a struct, Julia should be able to optimize it away if we don't know this. Emphasis on should...

[fingolfin]

Perhaps @fieker @thofma @ThomasBreuer have some thoughts about this?

[fieker]

I'd usually do sub(overgroup, G, elem) or similar?

[ThomasBreuer]

I remember we had discussions (a long time ago) about making GAP's ClosureGroup( G, H ) available in Oscar. This concept works whenever the two groups G, H do not need context information in order to decide what closure means. There is no problem for groups that come from GAP, but in general we might have to define closure for two embeddings into the same overgroup.

I think we had decided to leave out ClosureGroup until it turns out to be really useul/needed.