なぜ「a」のシーケンスにbzip2を使用する圧縮率が非常に急なのですか？

library(ggplot2)

compress <- function(str) {
  length(memCompress(paste(rep("a", str), collapse=""), type="bzip2"))
  / nchar(paste(rep("a", str), collapse=""))
}

cr <- data.frame(i = 1:10000, r = sapply(1:10000, compress))

ggplot(cr[cr$i>=5000 & cr$i<=10000,], aes(x=i, y=r)) + geom_line()

ここに画像の説明を入力してください

圧縮率は「a」で37から始まり、39「a」で損益分岐点に達します（圧縮率= 1）。チャートは非常に滑らかに始まり、98 "a"の間、そしてますます小さな間隔で突然エッジが上がります。

地元の安値と滑らかなセクションも非常に不安定とランダムに見えます。誰かがなぜBZIP2ショー私には、この例では、この動作を説明できますか？

data-compression

— ラファエル
ソース

a格納することによって実行を表す単純な圧縮アルゴリズム、つまり、固定ヘッダー、文字列、繰り返し回数。これはランレングスエンコーディングです。次いで、圧縮されたテキストの長さに近いであろういくつかの定数のビット。対応する圧縮率はます。ローカルの起伏を無視すると、これはおおよそ、遠くから見た曲線の形になります。漸近的に、圧縮比はと $(\text{header}, \mathtt{\text{"a"}}, n)$ a $n$ $a + \lg n$ $a$ $\dfrac{a + \lg(n)}{n}$ $\Theta(\lg(n)^p/n)$ $p \ge 1$ （私はそれを解決していませんが、入力文字列の長さで出力のサイズを超線形にする他の要因があると疑っています）。

$\lg n$ ビットは整数のビット数ではなく、バイトは言うまでもなく、のサイズは整数のバイト数に切り上げられた最小値でなければなりません。これは、最初のしきい値効果を説明しています。この単純な圧縮アルゴリズムではが十分に小さい場合、出力の長さがであり、、などであることがわかります。したがって、圧縮率はaではありません。滑らかな曲線ですが、から、次になどにジャンプします。この効果は、ジャンプ後の再配置ではほとんど見えません（ただし、ジャンプには別の効果があります）。 $n$ $a$ $n$ $a+1$ $a+2$ $\dfrac{a}{n}$ $\dfrac{a+1}{n}$ $\dfrac{a+2}{n}$

圧縮率は視覚的観測の長さの逆比に近すぎるため、ここに実装の短い長さのデータがあります（いくつかの入力を圧縮する方法は複数あるため、これはbzip2ライブラリのバージョンに依存する可能性があります））。最初の列はの数を示し、a2番目の列は圧縮された出力の長さです。

1–3       37
4–99      39
100–115   37
116–258   39
259–354   45
355       43
356       40
357–370   41
371–498   43
499–513   41
514–609   45
610       43
611       41
613–625   42
626–753   44
754–764   42
765       40
766–767   41
768       42
769–864   45
…

BZIP2ははるかに複雑で、単純なランレングス符号化という。これは一連のステップで機能し、最初のステップはランレングスエンコーディングステップですが、サイズ制限が固定されています。最初のステップは次のように機能します。バイトが少なくとも4回繰り返される場合、4番目以降のバイトを、消去されたバイトの繰り返しカウントを示すバイトに置き換えます。たとえば、（バイト値3の文字aaaaaaa）に変換されます。に変換されます。256個の異なるバイト値しかないため、この方法でエンコードできるのは、バイトが最大259回繰り返されるシーケンスのみです。さらにある場合は、新しいシーケンスが開始されます。また、リファレンス実装は、256バイトの文字列をエンコードする252の繰り返し回数、で停止します。aaaa\d{3}\d{003}aaaaaaaa\d{0}

このステップでは、最初のしきい値と258のしきい値について説明します。、 37バイトに、最大39バイトに圧縮します。繰り返しカウントの導入により、後続のステップの出力にさらに2バイトが追加され、その追加バイトは最大258までのすべての繰り返しカウントを表すことができます。258バイトの後、2番目のRLE文字列があります。514バイトに3番目、769バイトに4番目などがあります。2番目以降の余分なRLE文字列は、そのシーケンス（繰り返しカウントであると仮定して、チェックしていないと仮定）自体が繰り返され、したがって後続のステップで圧縮されるため、まったくコストはかかりません。 $\mathtt{a}^n$ $1 \le n \le 3$ $4 \le n \le 258$ aaaa\d{252}\d{252}

aaaa\374aa $n=258$ a

$n=100$ $\mathtt{a}^{101}$ aaaa\d{97}aaaaaa $n=101$ aA $68 \le n \le 83$

この例についての私の分析は、徹底的なものではありません。他の効果を理解するには、変換の他のステップを検討する必要があります。ほとんどの場合、ステップ1/9の後に停止しました。すべての詳細を本当に把握したい場合は、既存の実装を使用して、デバッガーでそれを観察することをお勧めします。

ほとんどの場合、圧縮アルゴリズムを設計するとき、このようなわずかなバリエーションは主な焦点ではありません。汎用またはメディア圧縮アルゴリズムなどの多くの一般的なシナリオでは、数バイトの違いは関係ありません。圧縮は、ローカルレベルですべてのビットを絞り出そうとし、変換を連鎖させようとします。それにもかかわらず、すべてのビットが重要な低帯域幅通信用に設計された専用通信プロトコルなどの状況があります。正確な出力長が重要な別の状況は、圧縮テキストが暗号化されている場合です：敵が圧縮および暗号化するテキストの一部を送信できる場合、暗号化テキストの長さの変化は、圧縮および暗号化されたテキストの一部を敵; HTTPS上のCRIME エクスプロイト。

— ジル「SO-悪であるのをやめる」
ソース