SQ documentation does not fit the algorithm

[hulpke]

The Documentation of the SQ describes that it finds a maximal quotient whose order divides the given order.

Peter Kenne observed (in an email) that this is not true.

As the algorithm (essentially a Plesken-style SQ) builds the quotient in steps, adding new chief factors, previous choices (and a random choice) can mean that there are larger, or different quotients.

The only plausible way to fix this is in the manual text, but this is difficult to describe without having to go into details of the implementation.

[dimpase]

Perhaps making it possible for SQ to be guided by an L-series, like it is for ANU SQ, is a way out.

PS. I'm still waiting to hear back from you regarding re-introduction of ANU SQ as a package.
See https://github.com/dimpase/anusq for a preliminary port.

[hulpke]

@dimpase You can already give parameters for a series, but even then an initial choice might pose restrictions later. The issue is basically concerning the claim of ``largest quotient''.

I think people would be interested in an port of ANUSQ (but I'm not the right person to ask). I suspect the main maintenance issue is to get the binaries compileable on the various platforms.

[dimpase]

On Wed, Apr 15, 2015 at 12:58:57PM -0700, Alexander Hulpke wrote:

@dimpase You can already give parameters for a series, but even then an initial choice might pose restrictions later. The issue is basically concerning the claim of ``largest quotient''.

my understanding of a typical series-driven algorithm is that on each level the maximum allowed
by the series factor is found, not just an irreducible factor fitting the bound, tightly or not.
Do I understand correctly that ANU SQ behaves this way?
I don't know whether SQ does this or not, if series-driven.

I think people would be interested in an port of ANUSQ (but I'm not the right person to ask). I suspect the main maintenance issue is to get the binaries compileable on the various platforms.

well, it's just C code, and it's either Linux or OSX nowadays (if you don't count
Cygwin). And its only tricky dependence is ve; once ve is sorted out, it should be trivial.

[olexandr-konovalov]

Thanks @dimpase - I've transferred the ve repository to https://github.com/gap-system/ve

[hulpke]

@dimpase What you describe is the (Leedham-Green, ANU)-SQ. The (Plesken-)SQ in GAP takes a known quotient, classifies modules in a characteristic, forms extensions and then checks whether the extension is compatible. I don't know off my head exactly, but I think the GAP implementation starts with small dimension modules first.

The module maximal dimension is often bound by a global quotient size factor -- that's the case where the problem occurs (if you classified all extensions with all modules you could run it as you describe).