# Техническое задание: Адаптивный пуловый генератор CRT-условий (gp2c-совместимая версия, ред. 2.1)
| Параметр | Значение |
|----------|----------|
| **Версия** | 2.1 |
| **Дата** | 2026-04-19 |
| **Статус** | Утверждено к реализации |
| **Целевой компилятор** | `gp2c -g` (PARI/GP → C) |
---
## 1. Цель
Разработать алгоритм, генерирующий **пул ранжированных CRT-систем**

, оптимизированных для поиска цепочек длины

с заданным количеством делителей

. Алгоритм должен динамически подбирать структуру модулей под любое

, контролировать реальный шаг перебора через

и полностью компилироваться в `gp2c` без предупреждений.
## 2. Термины и обозначения
| Термин | Обозначение | Тип | Определение |
|--------|-------------|-----|-------------|
| Длина цепочки |

| `int` | Количество последовательных чисел |
| Целевое

|

| `int` | Требуемое количество делителей |
| Модуль позиции

|

| `int` | `conds[k][i]`, гарантирует

|
| Остаточное

|

| `int` |

. Допустимый набор:

|
| Бюджет шага |

| `real` | `max_logLcm`. Ограничивает

|
| Начальное смещение |

| `int` | Решение CRT:

|
| Шаг CRT |

| `int` |

|
| Вес вероятности |

| `real` | Эмпирический приоритет остатка |
## 3. Математическая модель
### 3.1. Допустимые остатки и веса
Эмпирически установлено, что остатки

и

требуют редких структур (

или

) и **катастрофически снижают** плотность поиска. Они жёстко отсекаются.
|

| 4 | 8 | 12 | 2 | 6, 3 |
|----------|---|---|----|---|------|
|

| 1.00 | 0.55 | 0.05 | 0.15 | **0.0 (отсев)** |
### 3.2. Бюджет по НОК
Шаг перебора определяется

. Алгоритм обязан вычислять и ограничивать `log(lcm(M_i))`. Контроль через

не допускается как математически неточный.
### 3.3. Корреляции CRT
Структура CRT создаёт положительную корреляцию делителей соседних чисел. Совместная вероятность оценивается как:

## 4. Архитектура и этапы алгоритма
**Этап 1: Инициализация и пул простых**
- Предвыделение статических матриц `pool_conds[K,L]`, `pool_lcm[K]`, `pool_scores[K]`.
- Генерация массива простых до `primepi(max(2000, L+500))`.
**Этап 2: Распределение малых простых**- Для каждого

выбирается `offset` с минимальным числом конфликтов делимости.
- `offset` рандомизируется среди допустимых для обеспечения разнообразия пула.
-

назначается позициям, где

.
**Этап 3: Добивка с контролем `lcm`**
- Цикл продолжается, пока `log(pool_lcm[k]) < max_logLcm`.
- На каждом шаге ищется позиция с максимальным

.
- Подбирается наименьшее

, не использованное в текущей системе.
- Проверяется: `log(lcm(current_lcm, p^e)) <= max_logLcm` и допустимость нового

.
- При успехе обновляется `pool_conds[k]` и `pool_lcm[k]`.
**Этап 4: Решение CRT и фильтрация**
- Последовательное применение `chinese()`. При несовместности

система помечается `score = -1.0`.
- **Жёсткий фильтр**: если хотя бы одна позиция имеет

или

, система отбраковывается.
- Скор рассчитывается как

.
**Этап 5: Сортировка и дедупликация**
- Пул сортируется по убыванию

.
- Удаляются дубликаты по паре

. Хвост матрицы обнуляется.
## 5. Требования к gp2c-совместимости (Фактические)
1. **Комментарии:** Запрещён синтаксис `//`. Использовать только `/* ... */` или `\` для конца строки.
2. **Управление потоком:** Ключевое слово `continue` отсутствует в GP. Использовать `next`.
3. **Динамические структуры:** В строгом режиме `gp2c -g` не рекомендуется использовать `List()`, `mapcreate()`, `concat()` в горячих циклах. Предпочтительны статические `vector()`/`matrix()` с предварительным выделением памяти.
4. **Область видимости:** Все переменные должны быть объявлены в `my(...)` в начале тела функции.
5. **Синтаксис выражений:**
- Стандартное деление `/` допустимо без явного приведения типов.
- Конструкции `if(cond, action);` полностью валидны.
- Критично лишь корректное закрытие всех скобок `()`, `{}` и `[]`, а также отсутствие разрыва операторов `if(...)` символом новой строки внутри списка аргументов.
## 6. Выходные данные
Матрица размера `K × (5 + L)`:
`[ [L, T, x0, M, score, M_0, ..., M_{L-1}], ... ]`
Отсортирована по убыванию `score`. Недействительные системы имеют `score = -1.0` или нулевые строки.
## 7. Вспомогательные функции
| Функция | Вход | Выход | Назначение |
|---------|------|-------|------------|
| `analyze_chains(res, k_max, verbose)` | matrix, int, int | int(1/0) | Построчная статистика: плотности по позициям, распределение совпадений, оценка корреляции CRT |
| `generate_crt_pool(L, T, max_logLcm, max_mod, K, seed, verbose)` | int, int, real, int, int, int, int | matrix | Основной генератор с контролем `lcm` и динамическим подбором структур |
| `search_chains_fast(res, target, max_k, verbose)` | matrix, int, int, int | int | Оптимизированный поиск с прогресс-баром и ранним выходом |
## 8. Критерии успеха
1. **gp2c:** `gp2c-run -g script.gp` выполняется без ошибок и предупреждений. Время компиляции < 2с.
2. **Математика:** Пул содержит только системы с

. Бюджет `log(lcm)` не превышен. CRT-совместность гарантирована.
3. **Производительность:** При

генерация пула

занимает < 10 мс в скомпилированном виде. Поиск 50 цепочек на

шагов занимает < 3 сек.
4. **Стабильность:** Детерминированность при `seed`, корректная работа для

,

.5. **Анализ:** `analyze_chains` выводит статистику **по каждой системе отдельно**, позволяя выявлять "узкие" позиции (

с низкой плотностью).
## 9. Эмпирические ограничения и рекомендации
- Для

оптимальна конфигурация
![$\tau_R = [4,4,4,4,4,4]$ $\tau_R = [4,4,4,4,4,4]$](https://dxdy.ru/math/e9f171c16794183910c52f7a5e33104382.png)
или
![$[4,4,4,4,8,8]$ $[4,4,4,4,8,8]$](https://dxdy.ru/math/c501f374c8a943700814a12acec733a082.png)
с

.
- При

или

рекомендуется увеличивать `K` до 30–50 и ослаблять `max_logLcm` на 10–15%.
- Алгоритм использует жадную эвристику с оценкой `lcm`. Для

возможна частичная деградация плотности; в таких случаях предпочтительно увеличивать `pool_size`, а не бюджет.
---
✅ **Документ готов к использованию как эталонная спецификация для разработки, компиляции и сопровождения пулового генератора CRT-условий.**