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

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

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

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

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

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

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

BWT Rust-реализация (CUBR-0028, follow-up к H-13)

GO

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

H-16 — инженерное плечо H-13: рабочая BWT-реализация в Rust уже есть и питает H-20 (WIN). Стремиться: превратить прототип в production-grade BWT-движок — SA-IS/divsufsort-класс сортировка, u32-индекс (снятие 64K-лимита, FU-01), многопоточность по блокам, обратное преобразование без лишних аллокаций (IW-06 фиксирует: 10MB residual медленно даже параллельно). Качество сжатия даёт модель (H-13/H-20), H-16 отвечает за то, чтобы BWT-ветку можно было включить на 100MB enwik8 и 40MB webster без взры...

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

замер · CUBR-0046 E1f H-16 RT fix-forward full24 replay · 2026-07-16

Original commit 774fa4a deterministically failed RT on production files. Minimal fix-forward 5afe86d reserves context id 0 for the global Huffman fallback; full 24-file dev-ai replay RT=OK/cmp=0 on 24/24; world aggregate 0.9999641746694681. This is explicitly a fix-forward measurement, not the broken original binary.

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

общий 0.263589 · 9
canterbury/cp.html bwt-entropy 0.589156 canterbury/fields.c bwt-entropy 0.827444 canterbury/grammar.lsp bwt-entropy 1.003494 canterbury/sum bwt-entropy 1.000340 canterbury/xargs.1 bwt-entropy 1.003075 enwik8 bwt-entropy 0.262293 silesia/mozilla bwt-entropy 0.308247 silesia/samba bwt-entropy 0.196216 silesia/webster bwt-entropy 0.210721

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

NO-GO (bwt-entropy Rust: RT-fail на продакшн, superseded bwt-rans)

Далее: bwt-entropy (BWT+order-1 Huffman) superseded bwt-rans (H-19: order-1 rANS заменил Huffman, +25.9% rel). НЕ использовать standalone: round-trip FAIL на cp.html/fields.c/samba. Инженерное плечо BWT (bwt_encode_codes) переиспользовано в H-19/H-20 — там и живёт. Развивать production BWT-движок (FU-01 u32, IW-06 perf).

Уроки

Оба вендора NO-GO. Урок: Rust-реализация BWT+Huffman не исправила фундаментальную проблему round-trip на смешанном продакшн-корпусе; переписывание языка не чинит baseline-алгоритм. Ценность H-16 — рабочий BWT front-end, питающий rANS-чемпионов, а не сам Huffman-бэкенд.

2026-06-20
H-15

Distance-map enhancement на каноническом корпусе (CUBR-0028)

NO-GO

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

Улучшения карты расстояний на каноническом корпусе не дали выигрыша — NO-GO принят. Причина структурная: на больших файлах диспетчер уводит данные в LZ/CHUNKED-режимы, и карта расстояний просто не на критическом пути; а там, где CUBE остаётся (tiny-файлы), выигрыш съедается фиксированной стоимостью шапки. Не тратить усилия, **кроме случая X**: если IW-03/FU-02 вернут tiny-файлы (<64KB) на CUBE-конвейер с новым контекстным кодером — карта расстояний снова станет критическим путём, и точечные у...

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

замер · CUBR-0028 · 2026-06-20

NO-GO. Total distance-map RLE bytes = 26 (0.09% of 30217 T4 bytes). With positional i-order phi, phi(i) = (i%256, i//256), every cube cell [0..L-1] is occupied by construction → all gaps = 1 → RLE encodes trivially (≈4 bytes per axis per fi

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

CLOSED (NO-GO, historical CUBR-0028 — Gotcha #1)

Далее: Улучшение карты расстояний на каноническом корпусе структурно бесполезно: при positional i-order Φ все gap=1, карта = 0.09% байт. Переоткрывать только на sparse ρ<0.3 корпусе (что сломало бы baseline-сравнение).

Уроки

Карта расстояний несёт ~0% на плотном корпусе (26B из 30217 T4). Любая ветка усложнения добавляет mode-selector overhead с нулевой пользой. Gotcha #1: distance-map рычаг требует ρ<0.3 sparse входов — недостижимо без нового корпуса.

2026-06-20
H-14

Byte-level pre-processing (delta/MTF/stride-2 transforms, CUBR-0028)

NO-GO

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

Честно: слепые байтовые пре-трансформы (delta/MTF/stride) на общем корпусе доказанно не работают — вердикт NO-GO не оспариваем и усилий на «ещё раз попробовать то же самое» не тратим. Единственное живое направление — **таргетированные трансформы по детектору типа данных**, а не слепые: delta для табличных числовых записей, stride-N для многоканальных структур с известным периодом. То есть H-14 переезжает из «пре-процессинг вообще» в «пре-процессинг как часть per-type диспетчера». Условие re-o...

NO-GO — упёрлись в потолок; переоткрывать только при появлении нового класса файлов. Выигрыш реально живёт в контекстном моделировании (H-12/H-20).

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

замер · CUBR-0028 · 2026-06-20

NO-GO. Modelled aggregate 0.586365 (−0.149% vs T4, all three transforms). Root cause: delta and MTF INCREASE n_distinct on cube-mode files (text: 27→95, log_like: 53→82), inflating T4 per-code Huffman table overhead by 11× for text (814B→93

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

CLOSED (NO-GO, historical CUBR-0028)

Далее: Слепые байтовые пре-трансформы (delta/MTF/stride) на общем корпусе доказанно NO-GO — не переоткрывать. Живое направление — ТАРГЕТИРОВАННЫЕ трансформы под класс (BCJ для exe, MED для image, columnar для telemetry), которые и дали все выигрыши.

Уроки

delta/MTF УВЕЛИЧИВАЮТ n_distinct на cube-mode файлах (text 27→95, log 53→82), раздувая таблицу Huffman в 11× (814B→9314B) — стирают любую экономию битстрима. Слепой пре-трансформ = антипаттерн; выигрывают только информационно-обоснованные таргетированные трансформы (Gotcha #11).

2026-06-20
H-13

BWT-style value-stream reordering (CUBR-0028)

GO

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

BWT — наш магистральный путь к ppmd-классу на text без написания настоящего PPM. bzip2 доказал потолок наивного BWT, bsc/mcm доказали, что BWT + сильная контекстная пост-модель бьёт ppmd. H-13 (концепт) уже подтверждён, H-16 (Rust-реализация) и H-20 (order-2 context rANS поверх BWT) дали WIN. Стремиться: BWT-ветка как полноценный text-бэкенд диспетчера — большой блок (FU-01 u16→u32), сильная пост-BWT модель (order-3+SSE), скорость (IW-06), и авто-выбор BWT vs LZ vs CUBE через competitive-min.

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

замер · CUBR-0028 · 2026-06-20

РЕАЛЬНО (CUBR-0039, RT=OK, enwik8 incl): bwt-entropy 6/12 RT=OK — краш compress dickens/mr/x-ray + round-trip FAIL cp.html/fields.c/samba (enwik8 RT=OK 0.2623). Концепт validated (лог 0.504412 frozen), scheme ненадёжен на продакшн.

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

общий 0.263589 · 9
canterbury/cp.html bwt-entropy 0.589156 canterbury/fields.c bwt-entropy 0.827444 canterbury/grammar.lsp bwt-entropy 1.003494 canterbury/sum bwt-entropy 1.000340 canterbury/xargs.1 bwt-entropy 1.003075 enwik8 bwt-entropy 0.262293 silesia/mozilla bwt-entropy 0.308247 silesia/samba bwt-entropy 0.196216 silesia/webster bwt-entropy 0.210721

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

CLOSED (концепт validated → BWT-rANS champion line); bwt-entropy scheme NO-GO

Далее: Концепт BWT-переупорядочивания подтверждён и стал магистралью (породил чемпиона BWT+rANS H-19/H-20). Сам bwt-entropy (BWT+Huffman) scheme superseded rANS-веткой И ненадёжен на продакшн-корпусе. Развивать production-grade BWT (SA-IS, u32-индекс FU-01), не Huffman-бэкенд.

Уроки

Оба вендора NO-GO (по scheme). Синтез: концепт H-13 (BWT reordering снижает conditional entropy на структурированных данных) — WIN-родословная всего BWT-rANS семейства; но BWT+Huffman реализация round-trip FAIL на cp.html/fields.c/samba + краш на dickens/mr/x-ray. Урок: frozen-7-file GO (0.504412, 172 теста) НЕ гарантирует надёжность на продакшн-12-корпусе — расширенный корпус вскрыл RT-баги.

2026-06-20
H-12

Order-2 context-key Huffman (схема R6)

Рекорд ПОБЕДА

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

H-12 доказал главный принцип: контекстное моделирование значимо сильнее плоского энтропийного кодера на наших потоках. Сам order-2 Huffman уже морально устарел внутри кодека (H-19 rANS и H-20 order-2 context rANS его вытеснили), но идея «ключ контекста → отдельная таблица» — это зародыш полноценной context-mixing лестницы. Стремиться надо не к улучшению Huffman, а к обобщению схемы R6: контекстный ключ как first-class объект кодека, переиспользуемый любым бэкендом (rANS, ANS, будущий CM/PPM)....

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

замер · CUBR-0026 · 2026-06-20

РЕАЛЬНО (CUBR-0039, RT=OK, enwik8 incl): entropy-context-2 9/12 RT=OK overall 0.2569, avg-ratio слабый, краш dickens/mr/x-ray. Подтверждает CUBR-0027 NO-GO (order-2 Huffman +0.005 над T4).

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

общий 0.256917 · 9
canterbury/cp.html entropy-context-2 0.708613 canterbury/fields.c entropy-context-2 0.773363 canterbury/grammar.lsp entropy-context-2 0.761354 canterbury/sum entropy-context-2 1.000340 canterbury/xargs.1 entropy-context-2 0.770286 enwik8 entropy-context-2 0.262293 silesia/mozilla entropy-context-2 0.308247 silesia/samba entropy-context-2 0.196709 silesia/webster entropy-context-2 0.210721

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

NO-GO (2-of-2: order-2 Huffman слаб + краши)

Далее: Не использовать order-2 Huffman: fallback-таблицы съедают выигрыш (+0.005 над T4, CUBR-0027). Отказаться от глобальных fallback-таблиц в high-order Huffman. Идея контекстного моделирования жива, но реализована через rANS (H-19/H-20), не Huffman. Закрыт.

Уроки

Оба вендора NO-GO. Урок: order-2 Huffman неэффективен — выигрыш съедают накладные fallback-таблиц (Gotcha #6); rANS (sparse-таблицы + fractional bits) обошёл его. avg-ratio 0.59 (слабый) + краш compress на dickens/mr/x-ray.

2026-06-20

Страница 15 / 18