Write 4c entries (product action) as wreath elements by fingolfin · Pull Request #77 · gap-packages/primgrp

fingolfin · 2026-08-25T20:22:30Z

Rewrite entries of O'Nan-Scott type 4c, that is, subgroups of the full wreath product Sym(m) wreath Sym(k) embedded in Sym(m^k).

Right now, those generators are stored as permutations of degree m^k. We store them instead as tuples [ p_1, ..., p_k, sigma ], where the p_i are permutations of degree m, and sigma is a permutation of degree k. Thus storage is $O(mk)$ instead of $O(m^k)$.

With this, data goes from 30 M uncompressed / 12 M gzipped to 17 M uncompressed / 6.6 M gzipped.

Prepared with AI assistance (Claude Opus 5).

CC @hulpke @olexandr-konovalov @jesselansdown

Here it was critical that I taught Claude how to find the socle components, as MinimalNormalSubgroups in GAP was not equipped for it.

Should be squash-merged.

codecov · 2026-08-25T20:41:06Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.11%. Comparing base (d094e30) to head (8a0f0a0).

Additional details and impacted files

@@           Coverage Diff           @@
##           master      #77   +/-   ##
=======================================
  Coverage   99.11%   99.11%           
=======================================
  Files          46       46           
  Lines       38290    38324   +34     
=======================================
+ Hits        37950    37984   +34     
  Misses        340      340

Files with missing lines	Coverage Δ
data/gps1.g	`100.00% <100.00%> (ø)`
data/gps10.g	`100.00% <ø> (ø)`
data/gps11.g	`100.00% <ø> (ø)`
data/gps12.g	`100.00% <ø> (ø)`
data/gps13.g	`100.00% <ø> (ø)`
data/gps14.g	`100.00% <ø> (ø)`
data/gps15.g	`100.00% <ø> (ø)`
data/gps16.g	`100.00% <ø> (ø)`
data/gps17.g	`100.00% <ø> (ø)`
data/gps18.g	`100.00% <ø> (ø)`
... and 27 more

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

PGProductAction4c builds a type 4c group from generators written as elements of Sym(m) wreath Sym(k), which costs k permutations of degree m and one of degree k where a permutation of degree m^k stood before. Field 9 becomes ["4c", els] and says nothing else: k is the socle width in field 8 and m the k-th root of the degree. Taking such a group apart again is in tst/product4c.g rather than beside the converter, because it is wanted beyond the pass that writes data/: degrees 4096 to 8191 hold another 606 of these, and any later check that an entry is the group it claims to be does the same work. So it defines three functions and nothing else -- it reads no data and quits nothing -- and dev/product4c.g reads it. The socle T^k is split into its factors, whose orbits give the fibres of each coordinate and so the identification of the points with tuples; each generator then reads off as (p_1,...,p_k; sigma). Because the relabelling is a bijection, the group built back is the original conjugated by it, so the check is an identity and not a comparison of invariants -- and an entry is written only after that check passes, which is what makes every converted entry proven rather than merely reported. PRIMGRP_SocleComponents is the piece with a life of its own. Asking MinimalNormalSubgroups for the factors does not finish on the large socles: degree 1089 entry 6, whose socle is A(33)^2, takes over twenty minutes, and degree 2401 entry 1173 was left unconverted by earlier work after 5.8 hours. The factors are found by chance instead -- a random element of prime order lies in a single factor with high probability, its conjugates generate that factor plus some traces of the others, and the derived subgroup sheds those. Both entries now take five seconds and a minute. Nothing rests on the guess: a wrong factor gives the wrong number of fibres, and past that the rebuilt group fails to be the relabelled original. tst/testinstall/product4c.tst takes three groups apart and puts them back. That is an identity, every generator rebuilding as itself relabelled, so it holds whatever generators the random search happens to pick. Cost is dominated by Socle for the largest degrees -- 54 s at degree 3600, 130 s at 3844 -- so the converter rewrites its file after every entry and skips entries already converted, and dev/product4c-run.sh restarts it, blaming whatever the log last announced when nothing has been printed for a while. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

All 1108 type 4c entries of degrees 2 to 4095, converted by dev/product4c.g: gap -q -b -A --quitonbreak -l "ROOT;" -c 'conv_dir:="data";;' \ dev/product4c.g data/ falls from 30.88 MB to 17.04 MB, which is 45 per cent of it and rather more than every earlier pass together. Nothing but field 9 moves. Fields 1 to 8 of all 24558 entries were dumped before and after and are identical, which they have to be: the rebuilt group is the original relabelled, and a conjugate keeps its order, transitivity, suborbits and socle. Each entry carries its own proof, since the converter writes one only after checking that the group built back from the wreath elements is the original conjugated by the point relabelling. As an independent check, 35 entries spread across the range were rebuilt from the data and measured: degree, order, primitivity, transitivity and suborbits all agree with the entry. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Co-authored-by: Max Horn <max@quendi.de>

fingolfin changed the base branch from master to claude/projective August 25, 2026 20:22

fingolfin force-pushed the claude/projective branch 3 times, most recently from d88d5c6 to a671f52 Compare August 26, 2026 06:41

Base automatically changed from claude/projective to master August 26, 2026 07:20

fingolfin force-pushed the mh/product4c branch from d96d11e to ef97eae Compare August 26, 2026 07:35

fingolfin and others added 3 commits August 26, 2026 15:20

Cleanup dev

2096356

fingolfin force-pushed the mh/product4c branch from ef97eae to 2096356 Compare August 26, 2026 14:43