すべての入力メッセージを圧縮できる圧縮アルゴリズムはありませんか？

Guy E. Blellochによる、Introduction to Data Compressionという本を読み始めました。1ページ目で、彼は次のように述べています。

真実は、1つのメッセージがアルゴリズムによって短縮された場合、他のメッセージを長くする必要があるということです。これを実際に確認するには、GIFファイルでGZIPを実行します。実際、さらに進んで、固定長の一連の入力メッセージについて、1つのメッセージが圧縮されている場合、すべての可能な入力にわたる圧縮メッセージの平均長は、常に元のメッセージよりも長くなることを示すことができます。入力メッセージ。

たとえば、8つの可能な3ビットメッセージを考えてみます。1つが2ビットに圧縮されている場合、2つのメッセージが4ビットに拡張されなければならず、平均で3 1/8ビットになることを理解するのは難しくありません。

本当に？それを自分に納得させるのはとても難しいと思います。実際、これが反例です。3ビットの文字列を入力として受け入れ、次の出力にマップするアルゴリズムを考えます。

000 -> 0
001 -> 001
010 -> 010
011 -> 011
100 -> 100 
101 -> 101
110 -> 110
111 -> 111

だからあなたはそこにいます-入力はより長い出力にマッピングされていません。確かに4ビットに拡張された「2つのメッセージ」はありません。

それで、著者は正確に何を話しているのですか？私には明らかではないいくつかの暗黙の警告があるか、または彼はあまりにも抜本的な言語を使用しているのではないかと思います。

免責事項：私のアルゴリズムを繰り返し適用すると、実際にデータが失われることを理解しています。入力110に2回適用してみてください。110-> 000-> 0であり、110と000のどちらが元の入力であったかがわかりません。ただし、一度だけ適用すると、私にとっては無損失のようです。それは著者が話していることに関連していますか？

不足しているのは、サイズが3以下のすべてのビットを考慮する必要があるということです。つまり、サイズが3以下のビットの圧縮スキームで、3ビットの文字列の1つを2ビットの文字列に圧縮する場合、サイズが3以下の一部の文字列は 3ビット以上に拡張する必要があります。

losless圧縮方式が関数である単射であり、有限のビット列、すなわちに対して有限のビット列から、場合、次に、すなわち、一意に決定。C （x ）= C （y ）x = y C （x ）$C$$C(x) = C(y)$$x = y$$C(x)$$x$

任意の圧縮方式を考え、をバイナリ文字列のセットとする。比率計算することで、 がどのように機能するかを表すことができ 圧縮率は小さい方が良いでしょう。たとえば、場合、平均して文字列をを使用して50％圧縮できることを意味します。S C S 圧縮率（C 、S ）= Σ X ∈ S L E N G T H（C （X ）$C$$S$$C$$S$1/2S

長さが最大すべての文字列を圧縮しようとすると、問題が発生します。$n$

定理：レッツ一連のことが全て最大で長さの文字列及び任意の圧縮方式。次に、です。$S$$n$$C$$\text{CompressionRatio}(C,S) \geq 1$

したがって、世界で最高の圧縮方式は恒等関数です！まあ、ビットのランダムな文字列を圧縮したい場合のみ。実際に発生するビット文字列はランダムではなく、多くの規則性を示します。これが、上記の定理にもかかわらずデータを圧縮することが理にかなっている理由です。

Andrejの良い答えに対する追加のメモ：

コルモゴロフの複雑さを確認することもできます。

$s$$C(s)$$s$

$C(s)$$s$$C(s) \geq |s|$

2つの基本的な定理は次のとおりです。

$c$$s$$C(s) \leq |s| + c$$s$

$n$$s$$n$$C(s) \geq |s|$

$2^n$$n$$< n$

$\sum_{i=0}^{n-1} 2^i = 2^n - 1 < 2^n$

あなたの反例は間違っています。

圧縮された値のリストにはいくつかの隠された情報があり、実際には平均長が3ビットより長くなっています。追加情報は、出力文字列の長さです。

目で見ると、最初の出力文字列は1ビットのみで、その他は3ビットであることがテーブルからわかりますが、その事実を明示的にエンコードしないと不正行為をしていることになります。もう1ビット追加することでエンコードしましょう。0は「長さ= 1」を意味し、1は「長さ= 3」を意味します。

だからあなたのテーブルは本当に次のようになります：

000 -> 00
001 -> 1001
010 -> 1010
011 -> 1011
100 -> 1100 
101 -> 1101
110 -> 1110
111 -> 1111

...平均すると3.75ビットになります。

編集

これは、同じ点を示す後付けです。それは素晴らしいクイズの質問です：

モールス符号は、ドットとダッシュだけで構成されています。ドット0とダッシュ1と呼びます。すべての大文字は4ビット以下としてエンコードされます。

E = . = 0
Q = --.- = 1101

26の大文字があります。ただし、4ビットは16の異なる値のみをエンコードできます。どうしたの？

$2^{n+1}-1$$n$$n+1$。ただし、多くの文字列が最大長よりもはるかに短い場合は、最大文字列の長さに複数を追加し、短い文字列の長さを短くする別のコーディングスキームを使用すると役立つ場合があります。その結果、文字列の正確な長さを知ることによって伝えられる情報の量は、文字列がどれくらい長いと想定できるか、および短い文字列を埋め込む意欲に依存します。

そのような要因はアプリケーションに大きく依存するため、入力文字列に読者がそれらを終了する場所を知らせるのに十分な情報が含まれていると想定される計算モデルを想定すると役立ちます（たとえそれらに任意の量の任意のデータが埋め込まれても）。 、出力文字列も同様に行う必要があります。このような計算モデルにより、個々のデータレコードで機能するすべての操作が、データレコードの連結されたシーケンスでも機能するようになります[非圧縮レコード全体の読み取りをいつ停止するかを知るコードは、いつ停止するかを知っていると推定できます。圧縮されたもの全体を読み取る]。