Automorphism group design question

[thofma]

I have a few question about the design of the automorphism groups. Assume I have a group G and do A = automorphism_group(G). I am assuming that this is our goal as an interface for the user (or maybe it is not?).

• Does A have elements? What are these elements?
• If A has elements, how do they relate to ordinary morphisms that I could construct using say hom(G, G, blub). Will there be automorphisms (elements of A) and normal morphisms?
• If A has elements, I guess these can only be constructed if A is already constructed? So automorphism(G, g -> g^2) (just an example, not literally how I would want to enter it) could not work?

I am asking these questions because we are bolting stuff on the automorphism groups of abelian groups and I am trying to understand where we are going with this.

CC: @fieker @fingolfin @ThomasBreuer (and @simonbrandhorst since he added stuff in this direction)

[simonbrandhorst]

Yes A has elements. And probably also generators since I am interested in A as a group too. For instance I might ask for the order of A or define a group homomorphism from A to some other group. I think currently the elements are of type e.g. Oscar.BasicGAPGroupElem{AutomorphismGroup{GrpAbFinGen}}. Relevant for me is that they can be composed/multiplied and that they act on X and respect whatever structure X has. That seems to work so far. And I want to be able to define subgroups of A which remember that they consist of automorphisms, in particular they act on X too.

I have no clear cut opinion on the two other points. As long as automorphisms and homs can be composed I am fine.

[thofma]

What I imagine being challenging with this design will be subgroups and quotient groups. What is a subgroup? What will be its type? It cannot be of type AutomorphismGroup. So let's say it is AutomorphismGroupSubgroup. Since elem_type(parent_type(T)) === T and parent_type(elem_type(T)) === T, these subgroups need a distinct element type, say AutomorphismGroupSubgroupElement. What about subgroups of subgroups? What about quotients?

I am not sure what the answers to these questions are, but these will naturally pop up down the road and it would be good to figure these out first. Would be good to hear from the group theory experts in this regard.

[simonbrandhorst]

I see. What I have in mind and what I did not say, are groups consisting of automorphisms - not necessarily the full automorphism group. I do not have a use case for special dispatch on a full group of automorphisms.

[thofma]

I think similar problems appear for quotient groups, e.g., outer automorphism groups. I don't see how they can be groups of automorphisms of the original group or what they are supposed to be in this proposed design.

If automorphism groups will have their own type of group (which is one way to implement them), they should allow everything the other groups also support. This has been a constant source of irritation in some other computer algebra system, where automorphism groups are their own type but they support only little of the group functionality.

[fingolfin]

Quick answer: quotients can be any type, depending on the situation it can be perm group, fp group, pc group; I see no issue there.

And subgroups will be of the same type -- we didn't specify that instances of that type must be the full automorphism group. Perhaps there then should be a way to detect if a given automorphism group is the full group.

Uniqueness of the full group can be ensured by storing it as an attribute.

The fact that Oscar and Magma require parents is of course unfortunate when one wants to write down a single automorphism. One way to tackle that: automorphism groups could be computed lazily: only as an empty shell initially, which is filled out only when needed (eg when asking for the order or generators). Shouldn't be hard to achieve.

another option is to create the automorphism as a "plain" endomorphism that isn't stored as an automorphism. That may be better anyway, as it requires fewer consistency tests (but like in GAP we likely will want NC/nocheck variants of constructors anyway)