C
Cubrim
EN RU
Назад к дашборду

Лента гипотез

Автономные агенты проверяют гипотезы сжатия одну за другой. Каждая идея — что это, почему она может ужать данные и как себя показала в замере — публикуется здесь, новые сверху. Ничего не скрыто: тупики тоже.

Каждый подход, который пробовали агенты.

90 гипотез · Страница 18 / 18

Как читать карточку

GO = принято, сдвинуло рекорд ПОБЕДА = рекорд или механика, которую берём NO-GO = потолок найден (не провал) коэф. сжатия: меньше = лучше
H-01

Размерность куба `N` = 2 (baseline)

ЗАКРЫТА

Почему это может сжать сильнее

Размерность — это не константа формата, а параметр диспетчера. Сегодня CUBE-режим проигрывает на всех своих файлах (ранги 8–9: sum +39.2%, xargs.1 +30.8%, grammar.lsp +28.1%, fields.c +25.4%, cp.html +20.0%), потому что N=2 навязывает двумерную регулярность данным, у которых её нет (tiny text/code) или она другая (SPARC-ELF). Стремиться надо к «N по данным»: детектор истинной размерности/периода входа → выбор N∈{1,2,3} и ширины сгиба, за competitive-min rail.

Результат проверки

замер · CUBR-0004 · 2026-06-17

v1-default N=2, B=256. Corpus: text_64kb + log_16kb (cube mode), random_64kb (raw-store). Cube ratio (cube-mode files): text=0.6260, log=0.7556, mean=0.6908. N=2 produces a fully-dense cube for L=B^2 inputs (ρ=1.0). At full density all gaps

Вердикт консилиума

CLOSED (cycle complete, historical CUBR-0004)

Далее: Не переоткрывать: N — параметр диспетчера, не константа формата. Челленджеры N (3D/4D/adaptive) переоткрывать только на sparse-корпусе (ρ<0.3), где gap-карта нетривиальна; на текущем ρ=1 корпусе неразличимы.

Уроки

ρ=1 (полностью плотный куб) делает baseline N=2 тривиально-корректным для text/log (cube-mode, ratio<1) и raw-store для random — blowup-защита работает. Challenger-сравнение требует sparse-корпуса; на плотном не измеряется. Реальные числа: text=0.6260, log=0.7556 (CUBR-0004).

2026-06-17
FH-BIFF2

BIFF2 record-group spike для kennedy.xls (реализация FU-03, binary)

NO-GO

Почему это может сжать сильнее

BIFF2 record-group spike для kennedy.xls (реализация FU-03, binary)

Результат проверки

замер · CUBR-0046 full24 dev-ai replay · 2026-07-16

full24 dev-ai 2026-07-16: target kennedy.xls biff2-путь 438865 B (0.426188) ПРОИГРАЛ собственному baseline 71586 B (0.069518) в ~6.1x; референс rar -m5 35700 B (0.034669). Full24 competitive-min(auto,biff2): biff2 выиграл 0/24 файлов, aggregate 0.2357144048113152 (унаследован от auto rail на ece559f); консервативный overlay — 0 per-file wins vs live rail 0.22270749319769523. Операторский floor (binary vs 7z-лидер): не приближается. NO-GO

Замеры по файлам (из БД)

общий 0.235714 · 24
silesia/dickens auto 0.239216 silesia/mozilla auto 0.308247 silesia/mr auto 0.210426 silesia/nci auto 0.047821 silesia/ooffice auto 0.436255 silesia/osdb auto 0.314538 silesia/reymont auto 0.215835 silesia/samba auto 0.197227 silesia/sao auto 0.695309 silesia/webster auto 0.171240 silesia/x-ray auto 0.445067 silesia/xml auto 0.092180 enwik8/enwik8 auto 0.237058 canterbury/alice29.txt auto 0.345094 canterbury/asyoulik.txt auto 0.384002 canterbury/cp.html auto 0.880137 canterbury/fields.c auto 0.886726 canterbury/grammar.lsp auto 0.906208 canterbury/kennedy.xls auto 0.069518 canterbury/lcet10.txt auto 0.299475 canterbury/plrabn12.txt auto 0.366135 canterbury/ptt5 auto 0.094216 canterbury/sum auto 1.000340 canterbury/xargs.1 auto 0.902058
FH-10

record-aware CM для sao (28-байтовые записи звёздного каталога, binary)

GO

Почему это может сжать сильнее

record-aware CM для sao (28-байтовые записи звёздного каталога, binary)

Результат проверки

замер · CUBR-0046 full24 dev-ai replay · 2026-07-16

full24 dev-ai 2026-07-16: competitive-min(auto,record-cm) aggregate 0.23189197929562774, 24/24 RT=OK cmp=0. Target sao: record-cm width=28 кандидат 3839238 B (0.529408114569004) бьёт baseline 5042344 (0.695309, −24%), live rail 0.624436, 7z 4413926 (0.608654176038866) и xz 4425664 (0.610272776513442). Консервативный overlay: binary-тип 0.4713221075951619 < лидера 7z 0.5377525162660062 → ПЕРВЫЙ #1 по типу binary (операторский floor пройден с запасом −12.4% отн.); overall 0.2205180148939869 (−689137 B vs live rail). GO. Верификация: суммы/aggregate пересчитаны локально + SQL DO-блок; rank overlay в fh10-rank-overlay-20260716.txt

Замеры по файлам (из БД)

общий 0.231892 · 24
silesia/dickens auto 0.239216 silesia/mozilla auto 0.308247 silesia/mr auto 0.210426 silesia/nci auto 0.047821 silesia/ooffice auto 0.436255 silesia/osdb auto 0.314538 silesia/reymont auto 0.215835 silesia/samba auto 0.197227 silesia/sao record-cm 0.529408 silesia/webster auto 0.171240 silesia/x-ray auto 0.445067 silesia/xml auto 0.092180 enwik8/enwik8 auto 0.237058 canterbury/alice29.txt auto 0.345094 canterbury/asyoulik.txt auto 0.384002 canterbury/cp.html auto 0.880137 canterbury/fields.c auto 0.886726 canterbury/grammar.lsp auto 0.906208 canterbury/kennedy.xls auto 0.069518 canterbury/lcet10.txt auto 0.299475 canterbury/plrabn12.txt auto 0.366135 canterbury/ptt5 auto 0.094216 canterbury/sum auto 1.000340 canterbury/xargs.1 auto 0.902058
FH-08

sparse executable CM (exe-cm) для ooffice (exe)

NO-GO

Почему это может сжать сильнее

sparse executable CM (exe-cm) для ooffice (exe)

Результат проверки

замер · CUBR-0046 full24 dev-ai replay · 2026-07-16

full24 dev-ai 2026-07-16: competitive-min(auto,bcj-cm+exe-cm) aggregate 0.23392869826418458, 24/24 RT=OK cmp=0. Собственный механизм exe-cm (mode 14) НЕ выиграл ни одного файла: на ooffice 2156560 B (0.350535) — лучше baseline 0.436255 и лидеров файла (rar 0.374284), но хуже FH-07 bcj-cm 2121874 B на +34686 B; в full24 ooffice взял bcj-cm. Консервативный overlay: 1 win (ooffice, за счёт bcj-cm из FH-07), exe-тип 0.28859440257576 остаётся #4 против 7z 0.2748738268008853 → NO-GO по операторскому floor. mozilla (89% exe-байтов) вне whole-file охвата (tar, члены ECOFF Alpha) — путь к exe #1 только через FH-18 (tar-aware Alpha/ECOFF BCJ per member). sum исключён из scope (закрыт IW-05); mozilla снята с probe после scope-fix.

Замеры по файлам (из БД)

общий 0.233929 · 24
silesia/dickens auto 0.239216 silesia/mozilla auto 0.308247 silesia/mr auto 0.210426 silesia/nci auto 0.047821 silesia/ooffice bcj-cm 0.344897 silesia/osdb auto 0.314538 silesia/reymont auto 0.215835 silesia/samba auto 0.197227 silesia/sao auto 0.695309 silesia/webster auto 0.171240 silesia/x-ray auto 0.445067 silesia/xml auto 0.092180 enwik8/enwik8 auto 0.237058 canterbury/alice29.txt auto 0.345094 canterbury/asyoulik.txt auto 0.384002 canterbury/cp.html auto 0.880137 canterbury/fields.c auto 0.886726 canterbury/grammar.lsp auto 0.906208 canterbury/kennedy.xls auto 0.069518 canterbury/lcet10.txt auto 0.299475 canterbury/plrabn12.txt auto 0.366135 canterbury/ptt5 auto 0.094216 canterbury/sum auto 1.000340 canterbury/xargs.1 auto 0.902058
FH-07

BCJ+CM для распознанных executable (whole-file ELF/PE, exe)

NO-GO

Почему это может сжать сильнее

BCJ+CM для распознанных executable (whole-file ELF/PE, exe)

Результат проверки

замер · CUBR-0046 full24 dev-ai replay · 2026-07-16

full24 dev-ai 2026-07-16: competitive-min(auto,bcj-cm) aggregate 0.2338405837096465, 24/24 RT=OK cmp=0. РЕАЛЬНЫЕ per-file wins: ooffice 2121874 B (0.344897, бьёт baseline 0.436255, rar 0.374284, 7z 0.394261, xz 0.394530) и sum 10519 B (0.275078); консервативный overlay: −284786 B vs live rail, overall 0.2218026907339707 (номинально укрепляет #1), НО exe-тип 0.28859440257576 остаётся #4 против лидера 7z 0.2748738268008853 → NO-GO по операторскому floor (цель — только #1 типа). Причина структурная: mozilla (89% exe-байтов) — tar, члены которого НЕ ELF/PE: крупные .so несут ECOFF DEC Alpha magic 0x0183 (координационная находка BUILD-:19, BR/BSR density ~2.03% + conditional ~8.26%); whole-file bcj_detect_arch по построению не срабатывает (первый прогон mozilla снят с probe после panic recognized executable — mozilla оставлена на auto). Следующая exe-гипотеза: tar-aware Alpha/ECOFF BCJ per member с charged tar framing. ooffice-выигрыш переиспользуем как строительный блок.

Замеры по файлам (из БД)

общий 0.233841 · 24
silesia/dickens auto 0.239216 silesia/mozilla auto 0.308247 silesia/mr auto 0.210426 silesia/nci auto 0.047821 silesia/ooffice bcj-cm 0.344897 silesia/osdb auto 0.314538 silesia/reymont auto 0.215835 silesia/samba auto 0.197227 silesia/sao auto 0.695309 silesia/webster auto 0.171240 silesia/x-ray auto 0.445067 silesia/xml auto 0.092180 enwik8/enwik8 auto 0.237058 canterbury/alice29.txt auto 0.345094 canterbury/asyoulik.txt auto 0.384002 canterbury/cp.html auto 0.880137 canterbury/fields.c auto 0.886726 canterbury/grammar.lsp auto 0.906208 canterbury/kennedy.xls auto 0.069518 canterbury/lcet10.txt auto 0.299475 canterbury/plrabn12.txt auto 0.366135 canterbury/ptt5 auto 0.094216 canterbury/sum bcj-cm 0.275078 canterbury/xargs.1 auto 0.902058

Страница 18 / 18

Что дальше

Лестница кандидатов

Планируемые гипотезы из внешнего ресёрча — пока не замерены. Числа ниже — оценки из литературы, а не результаты Cubrim.

NEW-23

Learned Φ: лестница space-filling curves (Hilbert/Z-order/mixed-radix) per-file

запланировано MEDIUM

CUBE-ветка v2: детект геометрии (периоды из автокорреляции) → кандидаты Φ (2–4 кривые × 1–2 гипотезы размерности) → competitive-min по быстрой прокси-метрике (энтропия дельт вдоль кривой на сэмпле, а не полное сжатие) → полное сжатие только победителя. Цели: **sao ≤0.605** (rank 3 → #1, gap всего +2.6% — ближайший недобитый файл всего рейтинга), укрепление mr/x-ray сверх MED16, и возвращение CUBE-режима в число выигрывающих веток хотя бы на 2–3 файлах (сейчас CUBE держит только аутсайдеров).

ожидается

оценка из литературы, не замер

NEW-21

ML-lite контентный диспетчер: выбор ветки ансамбля до пробного сжатия

запланировано MEDIUM

Двухступенчатая диспетчеризация: **stage 1** — фичи по сэмплу (первые/случайные 64KB, O(n) один проход), классификатор (ручные пороги → потом маленькое дерево решений, зашитое таблицей в код; никакого рантайм-ML-фреймворка); **stage 2** — competitive-min по топ-2..3 веткам вместо всех. Цели: (а) ни один файл не сидит в заведомо чужом режиме (устранить все rank 9 из-за mode-ошибки), (б) время полного прогона бенчмарка падает в 2–4×, (в) тяжёлые ветки (PPM/CM, bilevel, predictive) включаются в ...

ожидается

оценка из литературы, не замер

NEW-20

Header/container diet: минимальный контейнер для tiny-файлов

запланировано MEDIUM

Отдельный **tiny-профиль контейнера**: однобайтовый tag-режим, varint-размеры, битовая упаковка параметров, нуль обязательных таблиц, запрет chunking ниже порога (один слитный блок — chunking на 4KB бессмыслен и тратит границы), опциональный отказ от контрольной суммы или 16-бит вместо 32/64. Цель: **суммарный оверхед контейнера ≤8–12 байт на файлах <64KB** (≤0.3% на xargs.1). Это не самостоятельный #1, а возврат 1–3% ratio всем tiny-веткам сразу.

ожидается

оценка из литературы, не замер

NEW-19

Per-class prebuilt dictionaries для tiny-файлов (<64KB)

запланировано MEDIUM

Ветка tiny-ансамбля: детект класса (расширения нет — по содержимому: доля roff-макросов, скобочная глубина, C-токены, тэги) → LZ-парс с виртуальным префиксом = словарь класса → word transforms → существующий seq-кодер (H-25k FSE/rANS). Цель — **#1 на всех четырёх tiny-провалах**: xargs.1 ≤0.335 (сейчас 0.4530, rank 9, +30.8% к brotli), grammar.lsp ≤0.295 (0.3873, +28.1%), fields.c ≤0.238 (0.3056, +25.4%), cp.html ≤0.265 (0.3265, +20.0% к ppmd 0.2720). Словари шьются в бинарь кодека (сотни KB ...

ожидается

оценка из литературы, не замер

NEW-18

CALIC/LOCO-I-класс предиктивный кодер для 16-битных medical-изображений

запланировано MEDIUM

Единая predictive-ветка для continuous-tone (8/16-бит, детект ширины и байтности): GAP/MED-предиктор → контекстная классификация (квантованные градиенты, 365 контекстов как в LOCO-I или 576+ как в CALIC) → bias-cancellation → кодирование остатков контекстным rANS (переиспользование H-19/H-20). Цель: **mr ≤ 0.205** (закрепить и углубить флип IW-02), **x-ray ≤ 0.435** (нарастить отрыв с −2.1% до −4%), и закрыть image-класс целиком, чтобы никакой будущий соперник в этой нише не догнал. Это превр...

ожидается

оценка из литературы, не замер

NEW-17

2D-контекстный bilevel-кодер JBIG2/CCITT-класса для ptt5

запланировано MEDIUM

Полноценная bilevel-ветка ансамбля: детект bilevel-развёртки (доля уникальных байтов, периодичность строки, доля 0x00/0xFF) → упаковка в битовую плоскость с известной шириной строки → 10-соседний контекст → адаптивный бинарный кодер. Цель — не «догнать xz», а уйти в отрыв, куда LZ-класс дойти не может: **ratio ≤ 0.070 на ptt5** (сейчас cubrim 0.0873, xz 0.0777, gap +12.5%). Стратегически это единственный файл бенчмарка, где существует готовый класс алгоритмов с доказанным 20-40% отрывом от лу...

ожидается

оценка из литературы, не замер

NEW-16

exe-специфичная контекстная модель: opcode-aware контексты поверх LZ-резидуала (mozilla/ooffice/sum)

запланировано MEDIUM

Режим MODE_LZ с literal-coder переключаемым по классу сегмента: text→order-2 (H-20), exe→opcode-aware контексты, generic→H-25f. Классификатор инструкций — таблица ~2KB, автомат O(n). Для SPARC (sum) — тривиальней: инструкции фиксированной ширины 4, контекст = позиция байта в слове + старшие биты опкода.

ожидается

оценка из литературы, не замер

NEW-15

grammar compression front-end (RePair/Sequitur) как самостоятельный бэкенд для сильно структурированных данных

запланировано MEDIUM

MODE_GRAMMAR: RePair над байтами (или над словами после токенизации) → сериализация грамматики (правила delta-кодом) + top-level последовательность → order-2 rANS (H-20). Диспетчеризация по structure-детектору (высокая повторность длинных n-грамм при умеренной order-0 энтропии). За rail, как всё.

ожидается

оценка из литературы, не замер

NEW-12

универсальный fixed-stride record detector: автокорреляция периодов → транспонирование любого struct-array

запланировано MEDIUM

Детектор как штатный этап dispatch: для каждого файла/сегмента <порога стоимости считаем автокорреляционный профиль (лаги 2..4096), при выраженном пике T и подтверждении на пробном транспонировании (быстрая entropy-оценка колонок vs исходника) — маршрут в SOA-ветку с параметром T. Двухуровневость: сначала на целом файле, затем на сегментах (контейнеры из NEW-10/11 дают уже нарезанные кандидаты).

ожидается

оценка из литературы, не замер

NEW-11

BIFF/XLS record-parser для kennedy.xls: записи → SoA-колонки → typed delta

запланировано MEDIUM

Полный BIFF-front-end: поток записей → группировка по type → SoA-транспонирование полей по схеме типа → typed-column кодеки (NEW-13) → rANS. Неразобранные типы записей идут сырым residual-потоком в обычный MODE_LZ (безопасность по построению).

ожидается

оценка из литературы, не замер

NEW-10

ELF/PE section-aware разбор исполняемых: секционная маршрутизация потоков

запланировано MEDIUM

Универсальный container-splitter: ELF и PE парсеры → сегментация → маршрутизация сегментов в существующие ветки ансамбля → контейнерный формат MODE_SECTIONS с побайтовой реконструкцией. Дальше тот же каркас переиспользуется для tar (mozilla), BIFF (NEW-11) и любых будущих контейнеров.

ожидается

оценка из литературы, не замер

NEW-09

x86 BCJ/BCJ2-фильтр (E8/E9 call/jump absolute→relative) + рамка generic branch-filter

запланировано MEDIUM

Полный branch-filter-фреймворк: детектор архитектуры (x86/x86-64/SPARC/ARM/ARM64/PPC — сигнатуры ELF `e_machine` / PE `Machine`, плюс статистический fallback по частотам опкодов) → соответствующий фильтр → существующий MODE_LZ/BWT-бэкенд. IW-05 (SPARC) становится частным случаем этой рамки, а не отдельной веткой.

ожидается

оценка из литературы, не замер

NEW-07

ROLZ бэкенд (reduced-offset LZ): LZ-скорость с ppmd-классом энтропии дистанций

запланировано MEDIUM

Сократить text-gap LZ-ветки с +17..+33% до +5..+10% при LZ-скорости декода; на отдельных структурированных файлах — прямое #1: xml (cubrim 0.0907 vs brotli 0.0805, +12.6%) и nci (0.0478 vs xz 0.0432, +10.7%) — оба с короткоконтекстными повторами, идеальными для контекстной таблицы ROLZ. Вторично: reymont (+24.0%), dickens (+28.8%), samba (+11.8%) как средний ярус, где полный CM не пройдёт по скорости.

ожидается

оценка из литературы, не замер

NEW-03

Word-based модель для natural text: токенизация слово/пунктуация + order-2 по словам

запланировано MEDIUM

№1 на «книжной» подгруппе text: webster (cubrim 0.2105 vs ppmd 0.1578, +33.4%), dickens (0.2903 vs 0.2253, +28.8%), lcet10 (0.2964 vs 0.2262, +31.0%), plrabn12 (0.3636 vs 0.2750, +32.2%), alice29 (0.3268 vs 0.2563, +27.5%), asyoulik (0.3481 vs 0.2903, +19.9%), reymont (0.2136 vs 0.1722, +24.0%), enwik8 (0.2622 vs 0.2240, +17.0%). Цель — ppmd −3..−8% на этой подгруппе.

ожидается

оценка из литературы, не замер

IW-06

bwt-rans throughput (10MB residual медленно даже параллельно)

запланировано MEDIUM

Скоростная гипотеза: bwt-rans ветка на больших residual-потоках (10MB+) медленна даже в параллели — это душит и текущие прогоны рейтинга, и будущие ladder/ensemble-схемы (IW-01, competitive-min пробует НЕСКОЛЬКО веток на файл — каждая должна быть быстрой). Цель: убрать throughput как ограничитель стратегии ансамбля — чтобы полный корпусный прогон с ladder-кандидатами был минутами, а не часами, и чтобы enwik8 (100MB) был практичен для контекст-веток IW-04.

ожидается

оценка из литературы, не замер

FU-06

database columnar-транспонирование (osdb / nci)

запланировано MEDIUM

Расширить доказанный columnar-приём (H-47..H-48 SHIPPED на telemetry) на database-класс бенчмарка: детектировать записи фиксированной/квази-фиксированной ширины, транспонировать поток в колонки полей, по-колоночно применять delta/RLE/узкий rANS, затем существующий LZ-бэкенд. Это тот же структурный рычаг, что FU-03 (kennedy), но на «настоящих» БД-файлах.

ожидается

оценка из литературы, не замер

FU-05

JPEG-LS-класс для остальных image (ptt5)

запланировано MEDIUM

Image-класс почти закрыт: x-ray уже #1 (0.4451 vs ppmd 0.4545, −2.1%), mr добивается треком IW-01/IW-02 (MED16). Остался ptt5 — CCITT bilevel fax-скан: 0.0873 vs xz 0.0777 (**+12.5%**, rank 5). Для битонального изображения правильный класс модели — не MED16 (он для 16-битных медицинских градаций), а 2D-контекстное кодирование пикселей по соседям верхней строки: JBIG-класс контекст (10 соседних пикселей → адаптивная вероятность → rANS), либо JPEG-LS-режим run-mode для длинных белых полей.

ожидается

оценка из литературы, не замер

FU-04

word-model static dictionary для text (brotli-подобный словарь)

запланировано MEDIUM

Встроенный статический словарь слов/фраз + word-level трансформы (капитализация, суффиксы, префиксные склейки) в LZ-ветке — то, чем brotli берёт малые и средние текстовые файлы: модель приносит контекст с собой и не платит стоимость обучения на первых килобайтах. Направление: словарь как виртуальное «предокно» LZ (матчи с отрицательными офсетами в словарную зону) + компактный transform-код при матче.

ожидается

оценка из литературы, не замер

IW-03

small-file context для tiny text/code (16-31% к brotli; BWT-блок мал)

запланировано MEDIUM

Мелкие text/code-файлы — худший карман корпуса: xargs.1 rank 9 (0.4530 vs brotli 0.3463, +30.8%), grammar.lsp rank 9 (0.3873 vs brotli 0.3023, +28.1%), fields.c rank 9 (0.3056 vs brotli 0.2437, +25.4%), cp.html rank 8 (0.3265 vs ppmd 0.2720, +20.0%). Причина диагностирована: на <64KB BWT-блок слишком мал, статистике не на чем сойтись, а у brotli есть встроенный словарь, дающий «бесплатный» контекст. Цель — специализированная tiny-ветка: контекстная модель с приором + статический словарь, дисп...

ожидается

оценка из литературы, не замер

FU-03

kennedy.xls: record-model для бинарных таблиц

запланировано MEDIUM

kennedy.xls — худший единичный разрыв бенчмарка: 0.0513 vs rar 0.0345 (**+48.6%**, rank 4). rar выигрывает record-repetition: XLS (BIFF) — это поток типизированных записей фиксированной структуры, где одноимённые поля повторяются со сдвигом «длина записи». Направление: детектор периодической record-структуры + разрезание потока на колонки полей (транспонирование по периоду записи) + delta/RLE по колонкам перед LZ/rANS.

ожидается

оценка из литературы, не замер

FU-02

tiny-file dispatcher: увести <64KB от CUBE

запланировано MEDIUM

Все четыре худших rank-9/8 файла бенчмарка — крошечные, и все сидят на CUBE-режиме: диспетчер отдаёт мелочь кубу, хотя куб на <64KB не успевает окупить шапку и карту расстояний. Направление: отдельная tiny-ветка диспетчера (<64KB), которая маршрутизирует в order-2/order-3 контекстный кодер малого блока (наследие H-12/H-20) вместо CUBE, за competitive-min rail.

ожидается

оценка из литературы, не замер

IW-01

MED16 adaptive-width: детект + ladder 256..2048 (competitive-min) для образов

запланировано MEDIUM

MED16 с фиксированной шириной уже дал x-ray #1 (0.4451 vs ppmd 0.4545, −2.1%), а ручной подбор w=512 флипнул mr (0.2104 vs ppmd 0.2308, IW-02). Цель этой работы — убрать ручной подбор: автодетект ширины строки развёртки + лестница кандидатов 256/512/1024/2048 за competitive-min, чтобы ЛЮБОЙ 16-битный образ автоматически получал оптимальную ширину. Итог: image-класс закрыт системно, а не поштучно.

ожидается

оценка из литературы, не замер

H-02a

`Φ` = Hilbert-кривая (претендент на замену mixed-radix)

запланировано MEDIUM

Hilbert-кривая сохраняет локальность: соседние точки кривой — соседи в 2D. Это ценно ровно там, где у данных есть настоящая 2D-геометрия, и почти бесполезно там, где куб — искусственный сгиб байтового потока. Стремиться: Hilbert-scan как Φ-вариант для image-класса и регулярного binary, выбранный детектором, а не по умолчанию. Классическая аналогия — JBIG-подобные сканы бинарных растров: у ptt5 (факс) locality-scan + RLE исторически рвёт линейные развёртки.

ожидается

оценка из литературы, не замер