Сверки

Потомки против библиотеки SmallGroups

Для $p$-группы $H$ $p$-класса $c \ge 2$ её родитель в дереве — $H / P_c(H)$, а шаг равен $\log_p |P_c(H)|$. Поэтому для $G$ порядка $p^m$ и шага $s$ непосредственные потомки группы $G$ — это в точности группы $H$ порядка $p^{m+s}$ с $H / P_c(H) \cong G$. desc_vs_sg.g сравнивает для каждой группы $G$ библиотеки и каждого допустимого $s$ мультимножество IdGroup групп PqDescendants(G : StepSize := s) с этим множеством (элементарные абелевы группы ранга $\ge 5$ — только при $s = 1$: большие шаги там занимают часы).

$p$	порядки $G$	пар $(G, s)$
2	$2 \dots 2^7$, потомки до $2^8$	3112
3	$3 \dots 3^5$, до $3^6$	125
5	до $5^5$	35
7	до $7^4$	12
11	до $11^4$	12

Это проверка pq на собственных презентациях библиотеки, которые совпадают с презентациями pq: дефект 1 она увидеть не может. Часть шагов больше ядерного ранга группы $G$; для них пустой ответ верен, но, как показывает дефект 15, pq приходит к нему через сбившийся диалог. Без PcgsAutomorphisms, как здесь, ответ получается верным.

Потомки других презентаций той же группы

Потомки группы не могут зависеть от её презентации. coords.g сравнивает PqDescendants(G : StepSize := 1) для $G$ = SmallGroup(n, k) ($n$ = 32, 64, 128, $p$-класс $\ge 3$, каждое третье $k$) с тремя изоморфными копиями: специальный pcgs, pcgs перестановочного представления и собственная презентация pq для fp-группы. На master в этом прогоне первое расхождение появляется на порядке 128 (SmallGroup(128, 3): 10 потомков, у копии 8), и до падения pq на SmallGroup(128, 1728) расходятся 17 групп; с исправлением 1: 1983 сравнений в каждом из четырёх прогонов, 0 расхождений, в том числе под AddressSanitizer с тремя затравками. Фиксированный список копий из таблицы дефекта 1 (gen_codes.g, check_codes.g) — воспроизводимый вариант этой проверки.

Стандартная презентация как ключ изоморфизма

spcheck.g: для каждой группы данного порядка её стандартная презентация задаёт эту группу (IdGroup от PcGroupFpGroup), разные группы получают разные презентации, а копии в другой pc-презентации — ту же самую.

порядок	групп	копий каждой
2	1	3
3	1	3
4	2	5
8	5	5
16	14	5
32	51	5
64	267	3
128	2328	1
243	67	3
625	15	3
729	504	1

Порядок 128: первый прогон оборвался, потому что pq был убит извне командой pkill, выполненной в ходе самого аудита («Открытые вопросы»); прогон повторяется на master и на correctness. Единственная смерть pq в прогоне порядка 64 имела ту же причину; порядок 64 пересчитан шесть раз (6408 вызовов) без единого сбоя.

Обход pq2048 с собственными накрытиями и детьми

С PQ2048_OWNCOVER=1 PQ2048_OWNDESC=1 проект D₅ строит $p$-накрытия функцией GAP Extension, а детей с шагом 1 — как их pc-факторы, и вызывает PqDescendants для этих детей: это ровно входы дефекта 1. Для всех 304 вершин порядков 16–64 класса $\le 3$ их 1186 детей сравнены с копиями из SmallGroups (потомки по IdGroup, до порядка 256): на master 0 расхождений. Дальше мы не проверяли; исправление снимает вопрос.

AddressSanitizer

pq, собранный с -fsanitize=address, прогнан с исправлениями на копиях выше и на проверке стандартных презентаций порядка 64: отчётов нет. На master падение из дефекта 1 — это heap-buffer-overflow в stabiliser_generators (stabiliser.c:173): с отображениями, которые не являются автоморфизмами, слово Шрайера не замыкается, и цикл пишет за конец рабочей памяти, которого никогда не проверяет (дефект 21). Во втором проходе ASan показал переполнения кучи из дефектов 12 и 21 на master и ничего — с их исправлениями; то, что видит только ASan при крошечной рабочей памяти, — на странице «Открытые вопросы». Падение из дефекта 4 отчёта не оставляет: pq завершается на входе, который ему не подходит.