The Memory Problem

(to finish properly - just a sketch so far)

The problem with the standard approach is that each stage of the resolution requries more and more memory to calculate. The `HAP` computes the resolution in the fast, naive way. The important stage here is computing the kernel of a module homorphism. In the standard `HAP` case, a homorphism is represented by a m by n|G| matrix of generators. This is expanded out to a full m|G| by n|G| F-homorphism matrix and the kernel found using &GAP;'s NullspaceMat, which needs about 2.5 times the storage of the input matrix.

HAPprime
makes more use of the module structure to compute the kernel without ever expanding the whole F-homorphism matrix, and so saving a lot of memory.

One solution is to divide the homorphism M into two halves (which we shall call U and V). The kernel of the homorphism is then the sum of the kernels of U and V, together with the pre-image in U and V of the intersection of U and V.

The kernels of U and V can be computed in exactly the same manner, so this part is divide-and-conquer. Unfortunately, the intersection of U and V cannot be computed in a divide and conquer manner. What is worse, the standard &GAP; method for computing the intersection of two spaces (SumIntersectionMat) would take 3.5 times the memory of the original m|G| by n|G| matrix, i.e. worse than the naive approach!

Solution 1: Using Compressed F-Echelon Representation

The standard method for calculating the intersection of two vector spaces starts with having a F-basis for both in echelon form. We have developed a method for expressing an echelon F-basis in a compressed form, which only takes about 1/30 the memory of expressing the full expanded F-basis. We can do this for each of U and V in turn, and then calculate the intersection while leaving one of them in compressed form: this only takes about twice as as much memory as the full expansion of either U or V.

However, this is slow and it it is not obvious how the memory usage can be reduced further.

Solution 2: G-Echelon Generators

The problem with Solution 1 is computing the intersection. Solution 2 massages the homorphism generators to make the intersection as small as possible (and ideally to zero).

The function EchelonModuleGenerators takes a set of module generators and returns a new set for the same module, but which are in something close to a semi-echelon form. Consider the following example: gap> G := SmallGroup(16, 5); <pc group of size 16 with 4 generators> gap> v := RandomMat(6, 64, GF(2)); <a 6x64 matrix over GF2> gap> DisplayModule(v,G); [...11.1.11...11.|1.1.111.11.1.11.|.......111..1111|11.1..11.1.11..1] [..1..1..1111.111|11..1..1....1..1|.1..11.11..1.11.|.....111....11..] [.111..1.1111.11.|...11111.1...1.1|.1.1111.....11.1|..1.11111.11....] [.1..11....11...1|111.1..1..1..111|.1.11....1.11..1|1.111.1.1111.111] [.1.1...1...1.1..|...1111..11.....|.1..1..1.....1.1|1111.11....11.11] [11....1.1..1.1.1|11.111111.11.1.1|1.111..1.......1|.1.1....1.1..11.] gap> e := EchelonModuleGenerators(v, G);; gap> DisplayModule(e.generators,G); [.1.1...1...1.1..|................|................|................] [................|...............1|................|................] [................|11....1......1..|................|................] [................|................|..111..1..1.11..|................] [................|................|................|11.1.1..1.111.1.] Both sets of vectors generate exactly the same vector space, but the generators after EchelonModuleGenerators are in a much nicer form. The modules generates by rows 1, 4 and 5 are independent, as is the module generated by the combination of rows 2 and 3. The nullspace of the overall matrix is simply the sum of the nullspaces of those four subspaces: there is no intersection to be calculated.

This split nullspace calculation can be performed using the function GensNullspaceGModuleNew: gap> GensNullspaceGModuleNew(rec(gens:=e.generators, group:=G)); [ <a GF2 vector of length 80> ]

In the case of the kernels required for a resolution, the decomposition is rarely as nice, but it is still hoped that the intersection will be small (this still needs checking, however!).