Implement "recognize An/Sn of unknown degree" algorithm by Jambor et al.

[ssiccha]

This is work in progress by @FriedrichRober and me.

Fixes #174.
Fixes #29.

[fingolfin]

Nice progress, folks :-)

[fingolfin]

Thank you once again for working on this!

I left some nitpicking comments, as my brain was/is too tired for more. I'll try to look with a more mathematical view in the coming days.

[codecov]

Codecov Report

Merging #176 (bd46e46) into master (36e0679) will increase coverage by 0.26%.
The diff coverage is 85.71%.

❗ Current head bd46e46 differs from pull request most recent head 068e69d. Consider uploading reports for the commit 068e69d to get more accurate results

@@            Coverage Diff             @@
##           master     #176      +/-   ##
==========================================
+ Coverage   78.00%   78.26%   +0.26%     
==========================================
  Files          39       41       +2     
  Lines       17480    18488    +1008     
==========================================
+ Hits        13635    14470     +835     
- Misses       3845     4018     +173     

Impacted Files	Coverage Δ
gap/utils.gi	26.74% <21.73%> (ø)
gap/SnAnBB.gi	80.65% <80.65%> (ø)
gap/generic/SnAnUnknownDegree.gi	97.06% <97.06%> (ø)
gap/base/hack.g	82.14% <0.00%> (-7.86%)	⬇️
gap/base/recognition.gi	67.64% <0.00%> (-0.67%)	⬇️
gap/projective.gi	88.41% <0.00%> (-0.66%)	⬇️
gap/generic/kernel.gi	89.33% <0.00%> (-0.55%)	⬇️
gap/projective/AnSnOnFDPM.gi	79.39% <0.00%> (-0.51%)	⬇️
gap/projective/findnormal.gi	77.74% <0.00%> (-0.37%)	⬇️
gap/projective/almostsimple.gi	65.40% <0.00%> (-0.27%)	⬇️
... and 9 more

[ssiccha]

Thanks for the suggestions!

[ssiccha]

In #28 I added an example or test (I don't remember which one it was) which we should be able to recognize efficiently with the unknown degree method.

I'm also not so sure anymore whether we should put the "unknown degree recognition" into the projective method databases or whether we should call it from inside recognition of classical or almost simple groups. According to #17 the "known degree recognition" was hooked up previously in almostsimple.gi:933.

For permutation groups it might make sense to put it into the method database.

[ssiccha]

@fingolfin We put a backup of the squashed version of our branch into this branch on my fork.

We now pushed a version of this branch which differs from the squashed one only by having several smaller commits instead of the huge Add algorithm SnAnUnknownDegree commit. We cleaned up the history and I hope it is understandable now. :)

These TODOs are left before this can be reviewed:

• Add more tests, especially for matrix groups, and check code coverage.
• Test An or Sn on a non-deleted permutation module. See tst/working/slow/NonDeletedPermModuleRepOfSn.tst (from Add example for recognizing An and Sn on non deleted permutation modules #28).
• Compare to the RECOG.RecogniseFDPM method in gap/projective/AnSnOnFDPM.gi. Maybe we can remove that entirely.

[FriedrichRober]

We also want to take a look if we can reduce the amount of iterations in BolsteringElements, since this seems to be a bottleneck, if we have as input an element c that is not a three-cycle.

[ssiccha]

Actually, I think, except for the tests, all of mine and @FriedrichRober's points from the previous two posts can be addressed in further PRs.

At the moment, testing Omega(-1,4,3) and Omega(0,5,3) make line 159 of tst/working/quick/GenericSnAnUnknownDegree.tst slow. It takes 70 seconds on my machine. I guess that may also be due to BolsteringElements.

With respect to the tests: coverage for SnAnUnknownDegree.gi is 97%. More or less the only things that were missing were having more matrix groups, more projective groups, and more groups not being isomorphic to Sn or An. I just added tests for these.

IMO this can be reviewed as it is now, especially since for me this is blocking some of the other PRs. I'd like to keep most of the commits in this PR to be able to pass the tests if they were checked out. So, @fingolfin could you have another look?