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


8

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のどちらが元の入力であったかがわかりません。ただし、一度だけ適用すると、私にとっては無損失のようです。それは著者が話していることに関連していますか?


13
あなたのコードはコードではありません。00010をどのようにデコードしますか?

3
実際には、鳩の穴の原理に依存しているこの事実の非常に単純な証拠があります。en.wikipedia.org/wiki/...
chazisop

すべての3ビットメッセージを3ビット以下に圧縮できれば、無限長のメッセージをほんの数ビットで圧縮できます。たとえば、提案が機能する場合は、最も多く発生する3ビットの値でxorを実行し、最初に値を追加して圧縮します。その後、メッセージが数ビットしかなくなるまで繰り返し続けます。
JarkkoL 2014

回答:


16

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

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

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

CompressionRatioCS=ΣバツSlegthCバツΣバツSlegthバツ
1/2SC

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

定理:レッツ一連のことが全て最大で長さの文字列及び任意の圧縮方式。次に、です。SCCompressionRatioCS1

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


ありがとうございました。だから著者は間違っていますね?彼は「固定長のメッセージ」と「8つの3ビットメッセージを考慮する」と言いましたが、「最大長が固定のメッセージ」と「最大3ビットの14の可能なメッセージを考える」と言ったはずです。
Jack M

@JackM:またはそれ以上:「アルファベットについて、長さが最大3のすべての文字列を検討する」{01}
Vor

7

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

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

sCss

CssCs|s|

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

csCs|s|+cs

sCs|s|

2<

Σ=012=21<2


4

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

圧縮された値のリストにはいくつかの隠された情報があり、実際には平均長が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の異なる値のみをエンコードできます。どうしたの?


これは本当に必要ですか?場合によっては、すべてのメッセージの前にその長さが固定幅のワードとしてエンコードされているプロトコルがある場合のように、長さを暗黙的にすることは完全に合理的であるように思えます。圧縮されているかどうかにかかわらず、すべてのメッセージの前にあるため、無視できます。そして、Andrejの投稿は、長さを暗黙のうちに許容しながら質問に答えるので、あなたの制限は不要のようです。もちろん、どちらにしても育てるのは良い点です。
Jack M

実際、長さを明示的にエンコードする必要があるというあなたの制限は、3ビット未満のすべての文字列をエンコードする必要があるというAndrejの制限と同等だと思いますか?
Jack M

@JackM:ほとんどの場合、単一のデータを他の(できれば小さい)単一のデータにマップするだけでなく、データのシーケンスを他の(できれば短い)シーケンスにマップするために圧縮スキームが使用されますデータの。入力シーケンスがすべて単一ストリームにあり、それらを細分割するのに十分な情報が含まれている場合、「入力長」には単一ストリームからの入力を解析するために必要なすべての情報を含め、「出力長」には出力を解析します。
スーパーキャット2014

0

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

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

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.