Added the missing perfect groups of order up to a million

[hulpke]

Added perfect groups of orders that had been missing in the Holt/Plesken book (newly computed). This increases the number of groups in the perfect groups library by a factor close to 6.

Also added 5 groups that were found missing in the existing lists.

[fingolfin]

This needs to be rebased on latest master: package bootstrap was temporarily broken because we moved file downloads to its own subdomain; now, of course we also set up a redirect, but it turns out we didn't configure curl to follow redirects... This was quickly fixed on master, but now this PR needs to be rebased to get the fix.

Sorry for the inconvenience. Also, 10% or so of Travis builds currently randomly fail because the downloads from gap-system.org alternate between blazing fast (5 seconds to download package tarball) to incredible slow (> 40 minutes do download). We are working during the ongoing virtual reality GAP Days on addressing this in some way.

[hulpke]

Sorry for the inconvenience. Also, 10% or so of Travis builds currently randomly fail because the downloads from gap-system.org alternate between blazing fast (5 seconds to download package tarball) to incredible slow (> 40 minutes do download). We are working during the ongoing virtual reality GAP Days on addressing this in some way.

Thank you for the explanation. I observed this weird behavior and was wondering whether anyone was aware of it. I suspect you have good ideas what to do about it and won't need me to second-guess possible workarounds.

[fingolfin]

At the core, it seems that the VM the University of St Andrews gives us to host the GAP web server is flaky (for many months now, it has been offline for a few seconds or minutes, multiple times per day); and recently, the bandwidth breaks down frequently, too. I have no idea what exactly is the cause, but in the end, it doesn't matter.

Right now, we are considering to just move the "default" downloads to the GitHub release system, which has been very reliable for us so far, and use the St Andrews only as backup. In addition, I may be able to offer hosting in Kaiserslautern, but maybe only after the Corona pandemic, as right now it is difficult to coordinate this with the computer admins.

[coveralls]

Coverage increased (+8.0%) to 93.729% when pulling 1b19738 on hulpke:fixes into dc28742 on gap-system:master.

[fingolfin]

A typos and a remark on the docs, but overall this is fine and of course a great addition to GAP!

[fingolfin]

@hulpke this still has the "do not merge" label; on purpose?

[hulpke]

Yes, the "Do not merge" is since I still want to run correctness tests.

Aded, Oct 1: Tests have run. I found a bug and this is fixed and the results corrected/rechecked.

[fingolfin]

These seem to be the relevant commits:

commit db7a8df486e0ca4a1f59b351f7340b4927be1008
Author: Jack Schmidt <[email protected]>
Date:   2005-11-24 18:51:28 +0000

    Added missing perfect group of order 450000, A6 2^1 # 5^4. Restricts nicely to A5 2^1 # 5^2, which is its minimal index corefree subgroup. JS

and

commit 2d5f94f342bd412cff4b95fb33fe3fd599a73e67
Author: Jack Schmidt <[email protected]>
Date:   2005-09-10 17:53:48 +0000

    First draft of adding in the perfect group of order 962280. JS

[hulpke]

@fingolfin Perfect (pun intened). Thank you! I'll add a remark.
[So it was 2005, which actually predates my current email archive...]

[ThomasBreuer]

@hulpke One more minor remark:
The changed behaviour of NumberPerfectLibraryGroups may break existing code, in the sense that the old variant allows one to run over the available perfect groups of order n via

List( [ 1 .. NumberPerfectLibraryGroups( n ) ], i -> PerfectGroup( IsPermGroup, i );

whereas the new variant forces one to check for fail before forming the range;
try for example

[ 1 .. NumberPerfectLibraryGroups( 1451520 ) ];

[hulpke]

@ThomasBreuer
I look at this as more of a hypothetical issue, but would be happy to reconsider if someone can point to concrete code out there that does this.

The issue of "available perfect groups" was much more a concern with the holes in the library. OTOH, the old convention of NumberPerfectLibraryGroups has the risk of a user misinterpreting it as NumberPerfectGroups and making wrong conclusions about existence of such groups.

The new behavior also is more consistent with the other group libraries, none of which distinguishes "Groups" from "LibraryGroups".

What probably however should be done with this change is to move NumberPerfectLibraryGroups on the way to obsolescence, e.g. have it issue a warning that points to NrPerfectGroups.

[ThomasBreuer]

@hulpke Well, this is how I found the hypothetical problem with the changed behaviour of NumberPerfectLibraryGroups:
I wanted to include the IDs of the relevant new groups from the perfect groups library in the character table library, and ran into an error (see ctbllib/gap4/ctdbattr.g, attribute "perf", function create).

[fingolfin]

Great job! That's definitely going to be a top tier in the release notes for 4.12 ;-)