ransbench 反証台
ransbench / 反証台
情報理論 · 適応モデル · rANS

圧縮の限界は
動かせなかった

「超圧縮」の構想から出発して、鳩の巣原理に殴られ、会計を作り直し、 実際に動く可逆圧縮器を書き、2ラウンドの候補を実測で落とすまで。 下のパネルはすべて操作できます。数値は実測値です。

実装した符号器
rANS 32bit
往復一致
SHA-256 OK
落ちた候補
4 / 4
01

鳩の巣は動かない

あらゆる入力を必ず縮める万能圧縮器は存在しません。k ビット縮めるには、 入力の 2⁻ᵏ しか収容先がないからです。スライダーを動かすと、 入力が実際に潰れていきます。

Pigeonhole 一意に戻せる入力 12.5%
一意に戻せる入力 衝突した入力(復元不能)
実測での裏取り:一様乱数 128 KiB を実装した符号器にかけると order0 8.1144 / order2 8.0152 / sse 8.0458 bpb。 すべて 8.0 を超える=理屈どおりに膨張します。この列が 8.0 を割ったらバグです。
02

ビットは消えず、デコーダへ移動する

「生成規則だけ送る」構想の穴はここでした。エンジンを共有した時点で、 その大きさは記述長に計上されます。1ファイルあたりの主張は、 償却するファイル数を書かない限り成立しません。

Two-part code / MDL 実効 — bpb
1 MiB のファイルを 1 つだけ送るなら、18.8 KB のエンジンは +0.143 bpb。10 GB のモデルを共有する構想なら、 この項が本体を何桁も上回ります。償却回数を書かない圧縮率は主張になりません。
03

rANS レジスタを回す

実装した符号器そのものです。32 ビットの状態レジスタ x に シンボルを押し込み、溢れる直前に 16 ビットずつ吐き出す。 確率を上げるほど消費ビットが減り、理論値 −log₂(f/T) に貼り付きます。

rANS · T = 2¹⁶ · L = 2¹⁶ 実測 32.0 bit 理論 32.0 bit
状態レジスタ x(32 bit)
出力テープ(16 bit ワード)
x65536
符号化数0
1シンボルあたり—
理論との差—
キャリー伝播が存在しないため、符号化と復号が代数的な逆関数対になります。 D(C(s,x)) = (s,x) は商・剰余の分解だけで閉じる短い補題で、 rANS を選んだ理由は速度ではなく証明の短さです。
04

実測:4 候補すべて落ちた

予測器だけを差し替え、符号器・演算・メモリ量・適応レートは固定。 比較の基準を切り替えてください。sse_hash は 「同じ文脈の無意味なハッシュ」=帰無モデルで、これに勝てない候補は 意味論ではなくパラメータ数を測っています。

Measured Δbpb
基準線より良い 基準線より悪い 基準線じたい
05

次の実験:8 値は足枷か

状態数を増やせば解像度は上がりますが、状態あたりのサンプルが減って適応が遅れます。 どこかに最適値があるはずで、それはデータ量とともに移動します。 下の曲線はモデルです。丸印だけが実測値です。

Dilution sandbox · モデル(未測定) 最適 N ≈ 8
希釈係数はまだ測っていないパラメータです。動かすと最適 N が動きます。 つまり「8 が足枷かどうか」はこの1本の実験で決まり、まだ決まっていません。 測るときは同じ状態数の sse_hash を並走させないと、 利得が容量由来か構造由来か分離できません。
06

測定値そのもの

bpb は小さいほど良い。すべて往復 SHA-256 一致を確認済み。

対照群は LZ もマッチモデルも複数次数混合も含まない意図的に最小の基準線です。 参考:同じ Python ソース 1 MiB で gzip -9 = 1.8572、bzip2 -9 = 1.5380、xz -9e = 1.5047 bpb。 汎用圧縮器に勝つためのものではなく、列間の差分を測るための土台です。