ロスレス圧縮アルゴリズムはエントロピーを削減しますか？

ウィキペディアによると：

シャノンのエントロピーは、決定された（または予測可能な）メッセージの部分とは対照的に、メッセージに含まれる情報を測定します。後者の例には、言語構造の冗長性や、文字や単語のペア、トリプレットなどの出現頻度に関する統計的特性が含まれます。

エントロピーは、メッセージに含まれる情報の量の尺度です。エントロピーコーダーは、そのようなメッセージを表現するために必要な最小ビット数（エントロピー）に可逆圧縮するために使用されます。私にとって、これは、メッセージを可能な限り損失なく圧縮するために必要なのは完全なエントロピーエンコーダーだけであるように見えます。

ただし、多くの圧縮アルゴリズムは、エントロピーコーディングの前にステップを使用して、メッセージのエントロピーを減らすと考えられています。

ドイツのウィキペディアによると

Entropiekodierer werdenhäufigmit anderen Kodierern kombiniert。Dabei dienen vorgeschaltete Verfahren dazu、die Entropie der Daten zu verringern。

英語で：

エントロピーコーダーは他のエンコーダーと頻繁に組み合わされます。前の手順は、データのエントロピーを減らすのに役立ちます。

つまり、bzip2はエントロピーコーディング（この場合はハフマンコーディング）を適用する前に、Burrows-Wheeler-Transformに続いてMove-To-Front-Transformを使用します。

これらの手順は、メッセージのエントロピーを実際に減らしますか？これは、メッセージに含まれる情報の量を減らすことを意味しますか？圧縮中に情報が失われ、無損失の圧縮解除が妨げられることになるため、これは私には矛盾しているようです。または、メッセージを変換してエントロピーコーディングアルゴリズムの効率を向上させるだけですか？または、エントロピーはメッセージ内の情報量に直接対応していませんか？

エントロピーは時々提示されるほどきちんとした整然とした尺度ではないため、エントロピーのカジュアルな記述の多くはこのように混乱しています。特に、シャノンエントロピーの標準定義では、Wikipediaが言うように、「独立したイベントによる情報は付加的である」場合にのみ適用されると規定されています。

つまり、独立したイベントは統計的に独立している必要があります。そうでない場合は、イベントを完全に独立させる方法でイベントを定義するデータの表現を見つける必要があります。そうでなければ、エントロピーを過大評価します。

さらに別の言い方をすれば、シャノンエントロピーは真の確率分布にのみ適用され、一般的なランダムプロセスには適用されません。シャノンエントロピーの仮定に適合しないプロセスの具体例については、以下を考慮してください...

マルコフ過程

マルコフプロセスは一連のイベントを生成し、1つ以上の以前のイベントに依存する分布から最新のイベントがサンプリングされます。明らかに、膨大な数の現実世界の現象は、離散的な独立した確率分布としてよりもマルコフ過程としてより良くモデル化されます。たとえば、あなたが今読んでいるテキスト！

単純に計算されたマルコフ過程のシャノンエントロピー率は、常にプロセスの真のエントロピー率以上になります。プロセスの真のエントロピーを取得するには、イベント間の統計的依存性を考慮する必要があります。単純な場合、そのための式は次のようになります。

また、これは表現することができますので、のように：

$\mu_i$

これは、特定のイベントの全体的な確率を計算できる場合でも、特定のイベントシーケンスが他のイベントよりもマルコフプロセスによって生成される可能性が高いことを示す複雑な方法です。そのため、たとえば、次の3つの英語の単語の文字列はますます少なくなります。

• 彼らは木に走った
• 木は彼らに走った
• 実行するツリー

しかし、シャノンエントロピーは3つの文字列すべてを同等に評価します。マルコフ過程のエントロピーはその差を考慮し、その結果、より低いエントロピー率をプロセスに割り当てます。

エントロピー率はモデルに依存します

ズームアウトすると、全体像がわかります。未知のソースからのイベントシーケンスのエントロピーレートはモデルに依存します。イベントを生成したプロセスをどのようにモデル化するかに応じて、特定の一連のイベントに異なるエントロピーレートを割り当てます。

そして、非常に頻繁に、プロセスのモデルが完全に正確になるとは限りません。これは単純な問題でも解決しやすい問題でもありません。実際、一般的に、真の基礎となるプロセスがわからない場合、イベントの十分に長く複雑なシーケンスに真のエントロピーレートを割り当てることは不可能です。これは、アルゴリズム情報理論の中心的な結果です。

実際には、イベントのシーケンスの未知のソースが与えられると、異なるモデルが異なるエントロピーを生成し、長期的にはどちらが正しいかを知ることは不可能です-最も低いエントロピーを割り当てるものがおそらく最良です。

いいえ、アルゴリズムがロスレスの場合、圧縮シーケンスのどのステップもエントロピーを低下させることはできません-そうでなければ、圧縮解除/復号化できません。ただし、追加のエントロピーは、「アウトオブバンド」情報に保存される場合があります。たとえば、リストのように、最前面への変換をデコードするために維持する必要があります。

それらは、元のメッセージの構造に固有の見かけのエントロピーを減らします。または、言い換えれば、次の圧縮段階の長所を利用するためにメッセージを調整します。

単純な例の1つは、xmlの終了タグ内の名前を特別なシンボルに置き換えることです。それから元のxmlを完全に再作成できますが、その場所に完全な名前を再度含める必要はありません。

より現実的な例は、png圧縮です。エントロピーコンプレッサーはDEFLATEです。これはLempel-ZiffとHuffmanの組み合わせです。これは、頻繁に繰り返される値とパターンで最適に機能することを意味します。ほとんどの隣接するピクセルは、類似した色になる傾向があります。そのため、各行には、元のピクセル値を差分エンコードに変換するフィルターが割り当てられます。これにより、DEFLATEでエンコードされる値はほとんど0に近くなります。極端な場合、これにより、LZ部分またはDEFLATEが非常に迅速に処理する行全体で、すべての異なる値からの滑らかなグラデーションが単一の値に変わります。

エントロピーコーダーは、メッセージを表現するために必要な最小ビット数にメッセージを圧縮しません。私はそれを考えるのは魅力的ですが、彼らがすることではありません。彼らは魔法ではなく、それを達成することはできません。

代わりに、彼らは少し魔法的ではないことをしますが、それでも有用です。メッセージの各文字が何らかの分布から独立して選択されていることがわかったと仮定します。その後、メッセージを最適に圧縮するロスレス圧縮アルゴリズムを構築することが可能です。これらのアルゴリズムは、エントロピーエンコーダーと呼ばれます。

現在、実際のメッセージには通常、その独立性プロパティがありません。たとえば、Qが表示される場合、次の文字がUである可能性があります。エントロピーエンコーダアルゴリズムを実際のメッセージに適用することは依然として可能です。各メッセージは、他の文字とは無関係に選択されません。アルゴリズムは引き続きロスレスであり、圧縮に使用することができ、実際には、メッセージの長さを短くすることがよくあります。ただし、可能な最小長に短縮されません。メッセージのエントロピーに等しい長さのメッセージにメッセージを圧縮しません。圧縮率はそれより小さくなります。

エントロピーエンコーダーのこの特性を理解すると、パラドックスは蒸発します。

一般に、損失のないステップはメッセージのエントロピーを決して減少させません。ただし、他の圧縮アルゴリズムがより効果的な形式にメッセージを配置する可能性があるため、実際には（平均して）依然として有用である可能性があります。

「エントロピー」という言葉は、2つの異なることを指すために、少し大雑把に使用されることが多い場合：

• メッセージまたはシステムの「情報の総量」

• 情報の「密度」、または情報がどれだけ密に詰まっているか。

Wikipediaのhttps://en.wikipedia.org/wiki/Entropy_(information_theory）のエントリに対するOPの引用は、最初のものを参照しています。

Shannon's entropy measures the information contained in a message

しかし、（少なくともこれを書いているときは）同じ記事は次のように始まります：

Information entropy is the average rate at which information is produced by a stochastic source of data.

そのため、1つは量であり、もう1つは速度です（距離と速度に似ています）。これらは「拡張」および「集中」プロパティと呼ばれることもあります（https://en.wikipedia.org/wiki/Intensive_and_extensive_properties#Extensive_propertiesを参照）。

区別の典型的な例は、ポール・リビアの有名なランタン信号です：「陸路なら1つ、海路なら2つ」。合計1ビットの情報（「北教会にまだ行っていない場合はなし」のケースを無視した場合）。ポールが建物の各ウィンドウに別のランタンセットを追加すると、それは '' '冗長' ''になります。これ以上の情報はないので、同じ「合計」または「広範な」エントロピー。ただし、メッセージの長さははるかに長く、「集中的な」エントロピーははるかに低くなります。

彼がその方法で開始したが、ランタンのセットを1つだけ使用するように変更した場合、それはOPの質問のように「ロスレス圧縮」です。「広範な」エントロピーは同じですが、「集中的な」エントロピーは異なります。2番目のウィンドウのランタンの数は、最初に見た数と大きく相関しているため、冗長なメッセージはより予測可能です。ランダム性が低いため、集中エントロピーがはるかに低くなります。

覚えておくべき他の2つの重要なことがあります。

• まず、通常、どちらの意味でもシステムの「真の」エントロピーを知りません。素朴な傍観者は、「3つのランタン」が異なるメッセージであるかどうか、または異なるウィンドウの信号が冗長であるかどうかを知りません。ポールが乗車を習慣にする場合、窓が常に一致するかどうかを数え、確認できます。しかし、たぶん私たちは、まれな（そしておそらく重要な！）例外を見るのに十分な長さを見ていないだけかもしれません。

• 第二に、どのように測定するかが重要です。連続する各テキスト文字によって伝達される量を推定しようとすることを検討してください（これはレートであるため、「相対」エントロピー、「相対エントロピー」とも呼ばれます）。

  • 人々が8ビット単位でテキストを送信していることに気づいた場合、最初の「見積もり」は1文字あたり8ビットかもしれません。
  • 使用されている個別の文字の数を数えると、log2（26）、または文字あたり4.7ビット（スペース、大文字小文字などを考慮すると少し高くなります）を見積もることになります。
  • 「z」よりも「e」の方が「次の文字」の方が適切だと考える場合、文字の頻度を測定して、4.14を取得します（http://people.seas.harvard.edu/~jones/cscie129/を参照してください）papers / stanford_info_paper / entropy_of_english_9.htm）。
  • 文字ペアを数えると、「qu」、「th」などのパターンを取得し、約3.56を取得します。
  • 最大で約5文字のシーケンスをカウントすると、さらに低い値が得られ、ボーナスとして、テキストがどの人間の言語であるかをかなり確実に区別できます。
  • 「印刷された英語の統計構造における長距離制約」（American Journal of Psychology 68（1955））でNG BurtonやJCR Lickliderと同じくらいハードコアで賢い場合、10のシーケンスを取得できます。連続して0000文字、さらに別のエントロピー値を見つけます。

しかし、もちろん、メッセージには、そのようなn-gramメソッドによってモデル化されていない多くのパターンが含まれる可能性があるため、「真の」エントロピーはさらに低くなります。

完全にランダムなトークンのZipfian分布を使用して理論上の無限ソースをモデル化すると、それが持つ広範囲かつ集中的なエントロピーを計算できます。その数が増えるにつれて、各タイプのエントロピーがどのように見えるかのグラフは[ http://www.derose.net/steve/writings/dissertation/Diss.0.html]にあります。2つの動作はまったく異なります。

• 合計（広範囲）：http : //www.derose.net/steve/writings/dissertation/Graph13.png
• 相対（集中）：http : //www.derose.net/steve/writings/dissertation/Graph14.png

助けになるか、少なくとも面白いことを願っています...

ドイツ語版ウィキペディアの言葉遣いは間違っていると思います。コンプレッサーはエントロピーを増加させます。つまり、全体のエントロピーではなく、ビットあたりのエントロピー、つまり情報密度です。たとえば、データを圧縮するために、ランレングスエンコーディングと辞書スキームが適用されます。同じ情報がより少ないビットにパックされるようになったため、各ビットはより多くの情報を伝達します。その後のハフマンコーディングは、同じことをもう少し行います。それは単なる圧縮の別のレイヤーです。