major parts of our dealing with orbits, dumping out permutations and stuff could be done more elegantly, that is delegating this sort of construction to GAP™ in some way or another. Of course when initially playing around with things, it has been easiest to work by brute force, that is by ourselves and not fiddling with any additional complications involved when trying to find analogies and using synergies. Now that we have reached an advanced understanding, perhaps it's time for a redesign here and there. Well, for the moment all stays as it is, there is no time for beauty
inverse problem: give automorphism or Galois group and recontruct the graph (several graphs in case there is no unique solution); ever wondered how the finite simple sporadic groups really look like? allowing non-zero torsion and boundaries, what is the smallest genus needed to visualize them on a 2-dim surface? and then actually, starting from the character tables perhaps, really do the construction concretely
the surfaces may change in time instead of being stable all the time (providing other labels for the holonomy groups then of course), that is to say: dump out the holonomy group on a simultaneously morphing graph, and relate the result to the original group (from the static graph)
the icosahedron is dual to dodecahedron, and on the other hand the term dual (dual space) is used for the <brak - ket> Hilbert product thing is there a connection? well yes, actually there seems to be not so much difference between Fourier analysis and character theory
complete the implementation of -rf and -rg export (full group)
finish the implementation of -q -s 2 for boundary graphs (that is, expressing rot in the same labels as used for the 'vector's)
perhaps the Loyd's 15 sliding puzzle could be modelled using the 'vector' groups approach? we feel that groups (the reflection at boundary idea is really nice) are superior to any groupoid thinking
'vector' groups (holonomy groups) for all types (not just type A)
rubik_3_2: 'faces connected over multiple (even neighboured) edges graph case (because two faces are then not enough to specify an edge): holonomy group and cover, and rubik_3_5 hanging in -q -s 4 cover