Cannot get perfect subgroups without data library

[olexandr-konovalov]

The following happens now in the master branch:

$ gapdev -r -A
 ┌───────┐   GAP 4.8.8-4417-g11e6f36 of today
 │  GAP  │   https://www.gap-system.org
 └───────┘   Architecture: x86_64-apple-darwin15.6.0-gcc-6-default64
 Configuration:  gmp 6.1.2, readline
 Loading the library and packages ...
 Packages:   GAPDoc 1.6, PrimGrp 3.1.2, smallgrp 1.2, transgrp 2.0
 Try '??help' for help. See also '?copyright', '?cite' and '?authors'
gap> Length(ConjugacyClassesSubgroups(SymmetricGroup(7):NoPrecomputedData));
Error, Cannot get perfect subgroups without data library! at /Users/alexk/GITREPS/gap/lib/grplatt.gi:1376 called from
RepsPerfSimpSub( G, false 
 ) at /Users/alexk/GITREPS/gap/lib/grplatt.gi:1480 called from
RepresentativesPerfectSubgroups( G 
 ) at /Users/alexk/GITREPS/gap/lib/grplatt.gi:401 called from
LatticeByCyclicExtension( G 
 ) at /Users/alexk/GITREPS/gap/lib/grplatt.gi:909 called from
LatticeSubgroups( G 
 ) at /Users/alexk/GITREPS/gap/lib/grplatt.gi:208 called from
<function "unknown">( <arguments> )
 called from read-eval loop at *stdin*:1
you can 'quit;' to quit to outer loop, or
you can 'return;' to continue
brk>

This is part of tst/testextra/grplatt.tst so not detected by Travis CI.

[olexandr-konovalov]

Traced this to the following: the error occurs when transgrp 2.0 package is loaded. When there is no transgrp package, GAP uses the trans directory instead, and then the example works fine.

[olexandr-konovalov]

So, with tracing methods for LatticeSubgroups we have

gap> Length(ConjugacyClassesSubgroups(SymmetricGroup(7):NoPrecomputedData));
#I  LatticeSubgroups: elementary abelian extension at /Users/alexk/GITREPS/gap/lib/grppclat.gi:1220
#I Trying next: LatticeSubgroups: via radical at /Users/alexk/GITREPS/gap/lib/grplatt.gi:841
#I  SetLatticeSubgroups: system setter
96

vs

gap> Length(ConjugacyClassesSubgroups(SymmetricGroup(7):NoPrecomputedData));
#I  LatticeSubgroups: elementary abelian extension at /Users/alexk/GITREPS/gap/lib/grppclat.gi:1220
#I Trying next: LatticeSubgroups: via radical at /Users/alexk/GITREPS/gap/lib/grplatt.gi:841
Error, Cannot get perfect subgroups without data library! at /Users/alexk/GITREPS/gap/lib/grplatt.gi:1376 called from
RepsPerfSimpSub( G, false ) at /Users/alexk/GITREPS/gap/lib/grplatt.gi:1480 called from
RepresentativesPerfectSubgroups( G ) at /Users/alexk/GITREPS/gap/lib/grplatt.gi:401 called from
LatticeByCyclicExtension( G ) at /Users/alexk/GITREPS/gap/lib/grplatt.gi:909 called from
LatticeSubgroups( G ) at /Users/alexk/GITREPS/gap/lib/grplatt.gi:208 called from
<function "unknown">( <arguments> )
 called from read-eval loop at *stdin*:20
you can 'quit;' to quit to outer loop, or
you can 'return;' to continue
brk> 

[ChrisJefferson]

I'm not sure this is a bug, or a problem.

[ChrisJefferson]

Oh sorry, I understand. I thought the problem was when you had no transgrp at all. Sorry.

[olexandr-konovalov]

Aha, next method to trace is RepresentativesPerfectSubgroups.

Now this works:

gap> Length(ConjugacyClassesSubgroups(SymmetricGroup(7):NoPrecomputedData));
#I  LatticeSubgroups: elementary abelian extension at /Users/alexk/GITREPS/gap/lib/grppclat.gi:1220
#I Trying next: LatticeSubgroups: via radical at /Users/alexk/GITREPS/gap/lib/grplatt.gi:841
#I  RepresentativesPerfectSubgroups: symmetric at /Users/alexk/GITREPS/gap/trans/trans.gi:174
#I  SetRepresentativesPerfectSubgroups: system setter
#I  SetLatticeSubgroups: system setter
96

but this does not:

gap> Length(ConjugacyClassesSubgroups(SymmetricGroup(7):NoPrecomputedData));
#I  LatticeSubgroups: elementary abelian extension at /Users/alexk/GITREPS/gap/lib/grppclat.gi:1220
#I Trying next: LatticeSubgroups: via radical at /Users/alexk/GITREPS/gap/lib/grplatt.gi:841
#I  RepresentativesPerfectSubgroups: symmetric at /Users/alexk/GITREPS/gap/pkg/transgrp/lib/trans.gi:176
#I Trying next: RepresentativesPerfectSubgroups: using Holt/Plesken library at /Users/alexk/GITREPS/gap/lib/grplatt.gi:1480
Error, Cannot get perfect subgroups without data library! at /Users/alexk/GITREPS/gap/lib/grplatt.gi:1376 called from
RepsPerfSimpSub( G, false ) at /Users/alexk/GITREPS/gap/lib/grplatt.gi:1480 called from
RepresentativesPerfectSubgroups( G ) at /Users/alexk/GITREPS/gap/lib/grplatt.gi:401 called from
LatticeByCyclicExtension( G ) at /Users/alexk/GITREPS/gap/lib/grplatt.gi:909 called from
LatticeSubgroups( G ) at /Users/alexk/GITREPS/gap/lib/grplatt.gi:208 called from
<function "unknown">( <arguments> )
 called from read-eval loop at *stdin*:21
you can 'quit;' to quit to outer loop, or
you can 'return;' to continue
brk> 

[olexandr-konovalov]

As we see now, RepresentativesPerfectSubgroups: symmetric at /Users/alexk/GITREPS/gap/trans/trans.gi:174 gives the answer, but when the package is used, it tries next Trying next: RepresentativesPerfectSubgroups: using Holt/Plesken library at /Users/alexk/GITREPS/gap/lib/grplatt.gi:1480. @hulpke do you know what happens here?

[olexandr-konovalov]

Well, the library code says:

  if not TransitiveGroupsAvailable(deg) then
    TryNextMethod();
  fi;

and the package code says

  if not TransitiveGroupsAvailable(deg) or
    ValueOption("NoPrecomputedData")=true then
    TryNextMethod();
  fi;
  Info(InfoPerformance,2,"Using Transitive Groups Library");

so because we use NoPrecomputedData option, of course when the package is there, GAP tries to use next method. When we use the trans directory, this is not happening and RepsPerfSimpSub is never called.

[olexandr-konovalov]

@hulpke do you think we can proceed as follows: to avoid TransGrp breaking existing GAP tests, change TransGrp to not to analyse NoPrecomputedData option, and then take time to resolve this properly?

There are more errors happening in the test in this setting. Some of them are apparently cause by the same reason, while some others are more alarming: e.g. the

testing: /Users/alexk/GITREPS/gap/tst/testextra/grpperm.tst
########> Diff in /Users/alexk/GITREPS/gap/tst/testextra/grpperm.tst:80
# Input is:
Length(ConjugacyClassesSubgroups(g));
# Expected output:
2048
# But found:
Error, Cannot get perfect subgroups without data library!
########
########> Diff in /Users/alexk/GITREPS/gap/tst/testextra/grpperm.tst:183
# Input is:
Size(Normalizer(SymmetricGroup(12),PrimitiveGroup(12,2)));
# Expected output:
#I  Using Primitive Groups Library
95040
# But found:
95040
########
########> Diff in /Users/alexk/GITREPS/gap/tst/testextra/grpperm.tst:195
# Input is:
Maximum(List([2..Length(ac)],x->Index(ac[x],ac[x-1])))<10^11;
# Expected output:
true
# But found:
false
########

and

########> Diff in /Users/alexk/GITREPS/gap/tst/teststandard/permgrp.tst:22
# Input is:
Maximum(List([2..Length(ac)],x->Index(ac[x],ac[x-1])))<600000;
# Expected output:
true
# But found:
false
########

While I might hope that the 3rd diff in testextra/grpperm.tst is caused by the two previous ones, the other diff in teststandard/permgrp.tst is just one for the whole test file - this does not sound right.

[hulpke]

First, this is exactly the problem with moving tests generously into testextra.

Secondly, I do not think that the issue is with the transgrp package. What you simply observe is that the `trans' directory never got the precomputed data option included as it was clear i would go away. I however hazard the guess that one could have run in exactly the same error without the package, by making up a suitable example.

The issue rather is with what precomputed data to allow: The lattice computation requires a list of perfect subgroups which is obtained from a list of precomputed data. In this case, we presumably must allow the use of this library of perfect groups, or the calculation has to stop. The error triggered thus is somewhat too bold a step.

I have thus changed the lattice code to have RepresentativesPerfectSubgroups

• if the option "NoPrecomputedData" is given - not run into an error, but to issue a warning that despite the option the perfect subgroups are taken from a library.

With this the problem goes away (only a warning is printed, which I consider appropriate.)

[fingolfin]

First off: glad to see @hulpke has a fix, thanks!

However, I don't see how this problem is caused by or related to "moving tests generously into testextra". Perhaps you mean to imply that the issue would have been noticed earlier if the test had been in testinstall? I am not so sure: we only catching things that break in testinstall because we now constantly run testinstall, but we can only afford to do so because it is fast, and that is so because we rigorously removed slow tests (or sped them up, where possible).
But nothing stops developers from running testextra on their local machines (but somehow, most rarely seem to do so...); and we still do check testextra, just not multiple times a day like we do with testinstall.

[olexandr-konovalov]

@hulpke thanks for the explanation! I will look how this will behave in PR #1809 then.