I am interested in the jumping champions of the number of groups of order $n$, where $n$ is cubefree.
After calling
LoadPackage("cubefree");
GAP gives the following jumping champions :
gap> maxi:=0; for n in [1..50000] do if IsCubeFreeInt(n)=true then s:=NrSmallGroups(n); if s>maxi then maxi:=s;Print(n,":",s,"\n"); fi;fi;od;
0
1:1
4:2
12:5
36:14
84:15
100:16
156:18
180:37
252:46
300:49
468:55
588:66
882:68
900:150
1764:228
3276:268
6084:298
6300:570
8820:672
11700:732
14700:771
16380:857
22932:1632
42588:1920
44100:3093
gap>
What is the next ?
I used NumberCFGroups from the Cubefree package and restarted the jumping champions and got :
gap> maxi:=0; for n in [50000..10^5] do if IsCubeFreeInt(n)=true then u:=NumberCFGroups(n); if u>maxi then maxi:=u; Print(n,":",u,"\n"); fi;fi;od;
0
50001:3
50002:4
50007:5
50010:8
50020:141
50148:259
50700:1154
54684:1417
62244:2270
So, the next champion must be greater than $62,244$.
Can anyone extend the table ?
I've calculated this for $1 \le n \le 10^5$ using
ParListWithSCSCP(see here) with one master and $48$ workers. This is an embarrassingly parallel calculation, and it took about half an hour on a 64-core Linux server with AMD Opteron 6375 1400MHz CPUs. It confirms that the next entry is given by $gnu(81900)=4087$, and there is no further champion for $81900 < n \le 100000$.I have a simple example of using SCSCP package for parallel search in the small group library at https://github.com/olexandr-konovalov/scscp-demo. Please remember that you should take care of load-balancing: for too short tasks, parallel calculation will most likely be slower than sequential, and the definition of "too short" depends on several factors, including the number of workers.