Maybe add more tests using `RECOG.testAllMaximalSubgroupsOfAtlasGroup`?

[fingolfin]

This function is currently only used in a single test (with M11), and that one is even disabled.

With BrowseAtlasContents(); one can get an overview of "supported" groups.

So e.g. RECOG.testAllMaximalSubgroupsOfAtlasGroup("A5"); "works".

So far all my tests with this passed, just performance was a problem, i.e. those tests run quite some time because there are so many representations in there ;-).

@SoongNoonien maybe you can play with this a bit next time

CC @ThomasBreuer in case he has any comments

[ThomasBreuer]

My interpretation of RECOG.testAllMaximalSubgroupsOfAtlasGroup is that the Web Atlas provides a lot of "real world" test examples for group recognition, and that it makes sense to run RecognizeGroup on all representations -- different characteristics, different dimensions, irreducible and not irreducible, etc.
Yes, this is something one does not want to run for each pull request that just fixes some comma in the documentation.

If one wants to do more specific tests then one can use the functions for programmatic access to the Web Atlas.

• AllAtlasGeneratingSetInfos( "M11", IsPermGroup ); yields the list of info records for the available permutation representations.
• AllAtlasGeneratingSetInfos( "M11", Characteristic, IsPosInt ); yields the list of info records for the available matrix representations over finite fields.
• AtlasSubgroup( info, k ); yields the group obtained by restricting the representation for the info record info to the k-th class of maximal subgroups (or fail if there are fewer maximal subgroups or if there is no SLP for the restriction).

One can restrict the lists to small degrees/dimensions if one wants, before actually downloading the data and constructing the generators.

RECOG.testAllMaximalSubgroupsOfAtlasGroup calls RECOG.TestGroup with the test group.
The first test in RECOG.TestGroup is to call RecognizeGroup and then to compare the known group order with that computed by RecognizeGroup.
This looks irritating:
The test group stores its order from the very beginning.
Is RecognizeGroup allowed to use this information?
If yes then the comparison makes no sense. Perhaps a group that is created anew from the generators should be used for the tests?

[SoongNoonien]

Is RecognizeGroup allowed to use this information?

As far as I can tell from the code and the docs at least Size (for recognition nodes) is not allowed to use the size of the group. It computes the size recursively by multiplying the sizes of images and kernels along the tree.

So, I'd say the comparison (Size(ri) <> size) should be justified.

[ThomasBreuer]

The point of the question

Is RecognizeGroup allowed to use this information?

is how RecognizeGroup( G ) is defined.
Is the meaning
"Ignore all knowledge stored in G, except for the generators, build a recognition tree for G, and return it"
or
"Build a recognition tree for G and return it"?

In the former case, the verification of the recognition tree is more expensive. In fact, then the question arises how one can enter knowledge (such as the group order) that can be used for shortcuts.