ハフマンコーディングが、Lempel-Zivができないエントロピーを排除するのはなぜですか？

人気のあるDEFLATEアルゴリズムは、Lempel-Zivの上にハフマンコーディングを使用します。

一般に、データのランダムなソース（= 1ビットエントロピー/ビット）がある場合、ハフマンを含むエンコードは平均して圧縮されません。Lempel-Zivが「完璧」である場合（長さが無限大になるにつれて、ほとんどのソースのクラスに近づきます）、ハフマンによるポストエンコーディングは役に立ちません。もちろん、Lempel-Ziv は少なくとも有限の長さでは完全ではないため、ある程度の冗長性が残っています。

ハフマン符号化が部分的に排除し、それによって圧縮を改善するのは、この残りの冗長性です。

私の質問は次のとおりです。この残りの冗長性は、LZではなくハフマンコーディングによって正常に除去されるのはなぜですか。ハフマン対LZのどの特性がこれを実現しますか？単純にLZを再度実行する（つまり、LZで圧縮されたデータをLZで2回エンコードする）と、似たようなことが行われますか？そうでない場合は、なぜですか？同様に、最初にハフマンで圧縮し、その後LZで圧縮しますか？

更新： LZの後でも、ある程度の冗長性が残ることは明らかです。数人がその点を指摘しています。明らかではないのは、なぜ残りの冗長性がLZよりもHuffmanによりよく対処されているのかということです。LZがハフマンよりもうまく機能する元のソースの冗長性とは対照的に、そのユニークな点は何ですか？

これはもともとコメントでしたが、長すぎました。

DEFLATEを見ると、Huffmanによって圧縮されているのはLZ77の出力です。LZ77は（これが生データよりも少ないビットを使用する場合）圧縮される文字列の早い段階でポインターを送信し、ポインターの後に取るシンボルの数を示す一致長を送信します。理論によれば、追加の圧縮を行わなくても、この手法は最終的にソースエントロピーに収束します。ただし、データ圧縮では、完全にランダムではない分布があるときはいつでも、圧縮することもできます。LZ77の出力（ポインターと一致の長さ）が完全にランダムであると信じる理由はありません。LZ77は漸近的に最適であるため、漸近的な極限で完全なランダム性に収束する必要がありますが、実際には有限の辞書のみを使用します。そのため、それらは完全にランダムになることから十分遠く離れたままであり、それらをさらに圧縮することで勝つことができます。当然、これら2つのプロセスの統計は異なるため、ポインターに1つのハフマンコードを使用し、一致長に別のハフマンコードを使用します。

2回目の圧縮にLZではなくハフマンを使用する理由 LZがハフマンに対して持つ大きな利点は、シンボル間の依存関係を扱うことです。英語では、ある文字が「q」である場合、次の文字は「u」である可能性が非常に高くなります。シンボルが独立したイベントである場合、ハフマンはより単純であり、短い文字列に対しても同様にまたはより良く機能します。LZ77の出力に関して、私の直感では、シンボルはかなり独立している必要があるため、ハフマンはより適切に動作するはずです。

データ圧縮とは、実際にはモデリングとエンコードの2つのことです。LZファミリーのアルゴリズムは、テキストを正確な繰り返しの連結としてモデル化します。これは、多くのランダムソースに対して漸近的に最適であり、多くの実際のテキストに対して適度に良好です。ただし、入力によっては、このモデルが非常に悪い場合があります。たとえば、サフィックス配列は元のテキストと同じように圧縮可能ですが、LZを使用してサフィックス配列を直接圧縮することはできません。

LZ77は、繰り返しごとに1つのタプルシーケンスとして入力をエンコードしますは以前の出現へのポインター、は繰り返しの長さ、は次の文字です。通常、このシーケンスには多くの（かなり長い）正確な繰り返しが含まれていないため、別のLZベースのアルゴリズムを使用して圧縮することはできません。代わりに、他のモデルを探す必要があります。のP ℓの$(p, \ell, c)$$p$$\ell$$c$

タプルの3つのコンポーネントのうち、ポインターは大きなランダムな整数と見なすことができるため、（長さ入力）ビットの整数としてエンコードすることは合理的な選択です。一方、繰り返しの長さは通常小さいので、大きい数よりも小さい数を優先するコードでエンコードする必要があります。ハフマンは適切なコーディングスキームの1つであり、他にもあります。繰り返し後の文字はおそらく均等に分散されていないため、ハフマンなどのゼロ次コンプレッサーを使用して、最も明白な冗長性を絞り出すことができます。$\log n$$n$

要するに、ハフマンはタプルの圧縮においてLZに勝っています。そのモデル（固定分布と正確な繰り返し）がデータによりよく一致しているからです。

答えはルックアップ辞書のサイズにあると信じています。

データには局所性の感覚があり（つまり、データの一部が使用されている場合、すぐに再び使用される可能性が高い）、LZアルゴリズムはルックアップ辞書の構築でこれを利用します。ルックアップを高速に保つために、有限量の可能なノードでトライを生成します。サイズの制限に達すると、前のものを「忘れる」という別のトライを行います。そのため、より単純な文字のルックアップテーブルを再度作成する必要がありますが、一部の単語が使用されなくなった場合、メモリに保持されなくなるため、より小さなエンコードを使用できます。

したがって、LZ出力はハフマンエンコーディングを使用してさらに削減できます。これは、ルックアップ試行の作成におけるこの冗長性が統計分析によって検出できるためです。

おそらく私はここで軌道に乗っていないかもしれませんが、Huffmanエンコードは入力全体を見てエンコードテーブル（ツリー）を構築しますが、Lempel-Zivは進行中にエンコードします。これは、ハフマンにとって利点でもあり欠点でもあります。欠点は明白です。つまり、開始する前に入力全体を確認する必要があります。利点は、Huffmanが入力の任意の場所で発生する統計を考慮に入れるのに対して、Lempel-Zivは漸進的にそれを構築する必要があることです。別の言い方をすれば、レンペルジブにはハフマンにはない「方向」があります。

しかし、これはすべて、物事がどのようになっているかを想像する私の単純な方法です。ここで、HuffmanがLempel-Zivよりも正確に優れていることを確認するには、ここで実際の証明が必要です。

簡単な答えは、LZはソースの正確な分布を知る必要がないという点で「ユニバーサル」アルゴリズムです（ソースが定常でエルゴードであるという仮定が必要なだけです）。しかし、ハフマンはそうではありません。（ハフマンツリーを作成するために）ソースがサンプリングされる正確な分布を知る必要があります。この追加情報により、ハフマンは厳しい圧縮保証を達成できます。ただし、実用的なファイル圧縮アルゴリズムの場合、Luffはオンラインで実装できますが、最初にファイルの経験的統計を収集してから後半に実際の圧縮を行う必要があるため、Huffmanはあまり好ましくありません。

詳細については、標準的な情報理論のテキスト、たとえばCoverとThomasによるElements of Information Theoryを参照してください。