[GAP Forum] Canonical form for some small groups and efficient characterisation of the generalized symmetric groups

[Joshua Hunt]

Dear Martin, Dear Forum,

I'm afraid I don't quite understand your objection to the SmallGroup 
library. What requirements does it not fulfil? Certainly one can change 
the small group ID back to a GAP group object with SmallGroup(), apply 
(for example) the Centre() function, and then use IdSmallGroup() to 
recover the ID of the centre. The small group identification is also 
unique for a given isomorphism class of groups, so you would get the 
same ID for the centre of the dihedral group of order 12 as for the 
permutation group on two letters. (You can also recover a 
human-readable, non-unique description of the group using 
StructureDescription.)

I would also point out that "groups of order less than 47" doesn't cover 
a lot of groups you probably would care about (e.g. 
symmetric/alternating groups S_5/A_5 and bigger, as mentioned in your 
example).

Best,
Josh

On 17/12/17 08:58, Martin Rubey wrote:
> Indeed, what I would have liked most is to simply use the small groups
> library IdSmallGroup.  Unfortunately, this does not quite work, let me
> explain:
> [...]
> The findstat database also contains maps between collections.  For
> example, there will be a map "automorphism group" from graphs to groups,
> a map "Weyl group" from finite Cartan types, a map "center" from groups
> to groups, etc. [besides: I could not come up with all that many
> interesting maps from groups to other objects, like permutations, yet]
>
> Thus, I additionally need to uniquely identify those finite groups that
> occur after applying a few (2 or 3) maps as image of some other small
> object.  For example, applying "automorphism group" to the complete
> graph on 6 vertices, or "Weyl group" to A_5 we get the symmetric group
> S_6, so this group needs to be uniquely identified.
>
> Being able to identify these images is not an absolute requirement - if
> some group occurs as an image and the "classification algorithm" fails,
> that's OK.  However, it has to be an isomorphism invariant, and it
> shouldn't fail "too often".  Also note that maps may be added in the
> future, so some level of robustness is necessary.