タグ付けされた質問 「data-compression」

ずいぶん前に、ある種の教授が将来、データをわずか2ビット（またはそのようなもの）に圧縮できると言っている新聞記事を読みました。 もちろんこれは正しくありません（そして、彼が正確に述べたことの私の記憶が正しくない可能性があります）。（技術的には可能であっても）0と1の文字列を2ビットだけに圧縮するのは実用的ではないことは理解できます。 'および' 10 'から選択）。 とにかく、これにより、何らかのスキームに従って0と1の任意の長さの文字列を圧縮することの実現可能性について考えるようになりました。この種の文字列について、文字列の長さ（0と1の比率はおそらく重要ではない）と最大圧縮の間に既知の関係がありますか？ 言い換えると、0と1の文字列を圧縮できる最小の（可能な限り短い）長さを決定する方法はありますか？ （ここでは、現在技術的に可能なものではなく、数学的な最大圧縮に興味があります。）

38 data-compression 

この考えは、プログラミングを学び、最初にPRNGに出会った子供として私に思いつきました。どれほど現実的かはまだわかりませんが、今ではスタック交換があります。 これは驚くべき圧縮アルゴリズムのための14歳のスキームです： PRNG sを取得し、シードでシードして、疑似ランダムバイトの長いシーケンスを取得します。そのシーケンスを別のパーティに送信するには、PRNGの説明、適切なシード、およびメッセージの長さを伝えるだけです。十分に長いシーケンスの場合、その説明はシーケンス自体よりもはるかに短くなります。 ここで、プロセスを逆にできると仮定します。十分な時間と計算リソースがあれば、ブルートフォース検索を実行して、目的のシーケンスを生成するシード（およびPRNG、つまりプログラム）を見つけることができました（猫のいたずらの面白い写真を見てみましょう）。 PRNGは十分な数のビットが生成された後に繰り返されますが、「典型的な」サイクルと比較すると、私のメッセージは非常に短いので、これは問題のようには見えません。 Voila、データを圧縮する効果的な（ルーベゴールドバーグ式の場合）方法。 したがって、仮定： 圧縮したいシーケンスは有限であり、事前にわかっています。 現金も時間も不足していません（両方の有限量が必要である限り） 知りたい： スキームの背後にある推論に根本的な欠陥はありますか？ この種の思考実験を分析する標準的な方法は何ですか？ 概要 良い答えが答えを明らかにするだけでなく、私が本当に求めていたのは何であるかを明らかにすることはしばしばあります。皆の忍耐と詳細な回答に感謝します。 答えの要約に対する私のn回目の試みは次のとおりです。 PRNG /シード角度は何も寄与せず、目的のシーケンスを出力として生成するプログラムにすぎません。 ピジョンホールの原則：長さ<= kの（メッセージを生成する）プログラムよりも、長さ> kのメッセージが多くあります。そのため、一部のシーケンスは、メッセージよりも短いプログラムの出力にはなり得ません。 プログラム（メッセージ）のインタープリターが必ず事前に修正されていることに言及する価値があります。そして、その設計は、長さkのメッセージが受信されたときに生成できるメッセージの（小さな）サブセットを決定します。 この時点で、元のPRNGのアイデアはすでに消滅していますが、解決すべき最後の質問が少なくとも1つあります。 Q：幸運にも、長い（しかし有限の）メッセージがたまたま<kビットの長さのプログラムの出力であることがわかりますか？ 厳密に言えば、可能性のあるすべてのメッセージ（プログラム）の意味を事前に知っておく必要があるため、偶然ではありません。それは <kビットのメッセージの意味であるかそうでないかです。 > = kビットのランダムメッセージをランダムに選択した場合（なぜですか？）、いずれの場合でも、kビット未満で送信できる確率はゼロになり、送信できないことはほぼ確実になります。使用するビット数はkビット未満です。 OTOH、kビット未満のプログラムの出力であるメッセージからkビット以上の特定のメッセージを選択すると（そのようなメッセージがあると仮定して）、実際にはすでに送信されたビットを利用していますレシーバー（インタープリターの設計）。転送されたメッセージの一部としてカウントされます。 最後に： Q：このエントロピー / コルモゴロフ複雑性ビジネスとは何ですか？ 最終的に、両方とも、（より単純な）鳩の巣の原理が圧縮できる量について教えているのと同じことを教えてくれます：おそらくまったくない、おそらくいくつかですが、確かに私たちが空想するほどではありません（チートしない限り）。

38 information-theory  randomness  data-compression  pseudo-random-generators  entropy 

ウィキペディアによると： シャノンのエントロピーは、決定された（または予測可能な）メッセージの部分とは対照的に、メッセージに含まれる情報を測定します。後者の例には、言語構造の冗長性や、文字や単語のペア、トリプレットなどの出現頻度に関する統計的特性が含まれます。 エントロピーは、メッセージに含まれる情報の量の尺度です。エントロピーコーダーは、そのようなメッセージを表現するために必要な最小ビット数（エントロピー）に可逆圧縮するために使用されます。私にとって、これは、メッセージを可能な限り損失なく圧縮するために必要なのは完全なエントロピーエンコーダーだけであるように見えます。 ただし、多くの圧縮アルゴリズムは、エントロピーコーディングの前にステップを使用して、メッセージのエントロピーを減らすと考えられています。 ドイツのウィキペディアによると 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を使用します。 これらの手順は、メッセージのエントロピーを実際に減らしますか？これは、メッセージに含まれる情報の量を減らすことを意味しますか？圧縮中に情報が失われ、無損失の圧縮解除が妨げられることになるため、これは私には矛盾しているようです。または、メッセージを変換してエントロピーコーディングアルゴリズムの効率を向上させるだけですか？または、エントロピーはメッセージ内の情報量に直接対応していませんか？

35 information-theory  data-compression  entropy 

サイズすべての無向グラフを列挙したいのですが、各同型クラスのインスタンスが1つだけ必要です。言い換えると、個の頂点上のすべての非同型（無向）グラフを列挙したいのです。これどうやってするの？nnnnnnn より正確には、次のプロパティを持つ一連の無向グラフを生成するアルゴリズムが必要です：個の頂点上の無向グラフごとに、がと同型であるようなインデックスが存在します。アルゴリズムが可能な限り効率的であることを望みます。言い換えれば、私が気にするメトリックは、このグラフのリストを生成して反復する実行時間です。第二の目標は、アルゴリズムが実装するのに複雑すぎないのが良いことです。G1,G2,…,GkG1,G2,…,GkG_1,G_2,\dots,G_kGGGnnniiiGGGGiGiG_i 各同型クラスから少なくとも1つのグラフが必要であることに注意してください。ただし、アルゴリズムが複数のインスタンスを生成する場合は問題ありません。特に、すべての可能なグラフをカバーしている限り、出力シーケンスに2つの同形グラフが含まれていれば、そのようなアルゴリズムを見つけやすくしたり、より効率的なアルゴリズムを有効にしたりすることができます。 私のアプリケーションは次のとおりです。サイズすべてのグラフでテストしたいプログラムがあります。2つのグラフが同型である場合、私のプログラムは両方で同じ動作をすることを知っています（両方で正しいか、両方で間違っています）ので、各同型クラスから少なくとも1つの代表を列挙し、次にテストするだけで十分ですそれらの入力に関するプログラム。私のアプリケーションでは、はかなり小さいです。nnnnnnn 私が検討したいくつかの候補アルゴリズム： 考えられるすべての隣接行列、つまり、対角線上にすべて0がある対称 0-or-1行列をすべて列挙できます。ただし、これには行列の列挙が必要です。これらの行列の多くは同型グラフを表すため、これは多くの労力を浪費しているようです。2 n （n − 1 ）/ 2n×nn×nn\times n2n(n−1)/22n(n−1)/22^{n(n-1)/2} 考えられるすべての隣接行列を列挙し、それぞれについて、以前に出力したグラフのいずれかと同型かどうかをテストできました。以前に出力されたものと同型でない場合は、出力します。これにより、出力リストが大幅に短縮されますが、少なくともステップの計算が必要になります（グラフの同型チェックが超高速であると仮定した場合でも）。私のメトリック。2n(n−1)/22n(n−1)/22^{n(n-1)/2} 隣接行列のサブセットを列挙することは可能です。特に、が個の頂点グラフである、一般性を失うことなく、なるように頂点が配置されていると仮定できます。。言い換えれば、すべてのグラフは、頂点が非減少度の順に配置されているグラフと同型です。そのため、このプロパティを持つ隣接行列のみを列挙すれば十分です。そのような隣接行列がいくつあるのか正確にはわかりませんが、よりもはるかに少なく、GGGnnnV={v1,…,vn}V={v1,…,vn}V=\{v_1,\dots,v_n\}degv1≤degv2≤⋯≤degvndeg⁡v1≤deg⁡v2≤⋯≤deg⁡vn\deg v_1 \le \deg v_2 \le \cdots \le \deg v_n2n(n−1)/22n(n−1)/22^{n(n-1)/2}2n(n−1)/22n(n−1)/22^{n(n-1)/2}計算のステップ。ただし、これによって多くの冗長性が残ります。多くの同型クラスが何度もカバーされるため、これが最適であるとは思えません。 もっと良くできますか？正しく理解すれば、約非同型グラフの等価クラス。上記のアルゴリズムより実行時間が良いアルゴリズムを見つけることができますか？どれだけ近づくことができますか下限？私は主に小さな扱いやすさ（たとえば、または程度;そのようなアルゴリズムを完了までもっともらしく実行できるほど小さい）を気にし、大きな漸近性についてはあまり気にしません。2n(n−1)/2/n!2n(n−1)/2/n!2^{n(n-1)/2}/n!∼2n(n−1)/2/n!∼2n(n−1)/2/n!\sim 2^{n(n-1)/2}/n!nnnn=5n=5n=5n=8n=8n=8nnn 関連：等価でないバイナリ行列を構築します（残念ながら、有効な答えを受け取っていないようです）。

30 algorithms  graphs  data-compression  graph-isomorphism 

から2 n − 1の順序付けられた2進数を含むファイルがあります。0002n− 12n−12^n - 1 0000000000 0000000001 0000000010 0000000011 0000000100 ... 1111111111 7zはこのファイルを非常に効率的に圧縮しませんでした（n = 20の場合、22 MBは300 kBに圧縮されました）。 データの非常に単純な構造を認識し、ファイルを数バイトに圧縮できるアルゴリズムはありますか？また、CSや情報理論のどの分野がこのようなスマートアルゴリズムを研究しているかを知りたいです。「AI」は広すぎるため、より具体的なキーワードを提案してください。 対称性の概念はデータ圧縮で基本的な役割を果たすはずですが、検索クエリ「データ圧縮の対称性」と「データ圧縮の群論」は、驚くべきことにほとんど何も関連性を返しません。

27 information-theory  data-compression 

ある人は次のように言った： 決定論的な手段で乱数を生成しようとする人は、もちろん罪の状態に住んでいます。 これは常に、コンピューターだけでは真の乱数を生成できないことを意味します。そして彼は、コンピューターが単一のIntel 8080マイクロプロセッサーと同等のサイズ（約6000バルブ）だったと言いました。コンピューターはより複雑になり、フォン・フォン・ノイマンの声明はもはや真実ではないと思う。実装されたソフトウェアのみのアルゴリズムは不可能であることを考慮してください。これらは物理ハードウェア上で実行されます。真の乱数ジェネレーターとそのエントロピーソースもハードウェアで構成されています。 このJavaフラグメントはループに入れられます。 file.writeByte((byte) (System.nanoTime() & 0xff)); 画像として表したデータファイルを作成できます。 構造を見ることができますが、同様に多くのランダム性があります。興味深いのは、このPNGファイルのサイズは232KBですが、250,000のグレースケールピクセルが含まれていることです。PNG圧縮レベルは最大でした。つまり、圧縮率は7％だけです。かなり非圧縮性。また興味深いのは、ファイルが一意であることです。このファイルのすべての世代はわずかに異なるパターンであり、圧縮率は約7％です。 私の主張にとって重要であるため、これを強調します。これはバイトあたり約7ビットのエントロピーです。もちろん、より強力な圧縮アルゴリズムを使用すると削減されます。ただし、0ビット/バイトに近い値に減らさないでください。上記の画像を撮影し、そのカラーマップをランダムな画像に置き換えることで、より良い印象を得ることができます。 構造のほとんど（上半分）は、類似しているがわずかに異なる値のシーケンスであるため、消えます。これは、マルチテイキングオペレーティングシステムでJavaプログラムを実行するだけで作成される真のエントロピーソースですか？一様に分布した乱数ジェネレータではなく、1つのエントロピーソースですか？たまたまPCである物理ハードウェアで実行されるソフトウェアで構築されたエントロピーソース。 補足 すべてに共通の固定パターンなしですべての画像が新鮮なエントロピーを生成することを確認するために、10個の連続した画像が生成されました。次に、これらを連結し、私がコンパイルできる最強のアーカイバ（paq8px）で圧縮しました。このプロセスは、変更/エントロピーのみを残す自動相関を含む、すべての一般的なデータを削除します。 連結されたファイルは〜66％に圧縮されており、エントロピー率は〜5.3ビット/バイトまたは10.5Mbits / imageになります。驚くべき量のエントロピー⌣⌣ \smile 補足2 圧縮テストの方法論によるエントロピーに欠陥があるという否定的なコメントがあり、緩やかな上限推定値を示しているだけです。NISTの公式暗号エントロピー評価テストSP800-90B_EntropyAssessmentを使用して、連結ファイルを実行しました。これは、非IIDエントロピー測定の場合と同じくらい良好です。これはレポートです（この質問は長くなっていますが、問題は複雑です）： Running non-IID tests... Entropic statistic estimates: Most Common Value Estimate = 7.88411 Collision Test Estimate = 6.44961 Markov Test Estimate = 5.61735 Compression Test Estimate = 6.65691 t-Tuple Test …

25 randomness  data-compression  entropy  random-number-generator 

私は最近、データのタイプや形式に関係なく、ランダムデータセットを常に50％以上効率的に圧縮すると主張する次の興味深い記事に出会いました。 基本的に、素数を使用して4バイトのデータチャンクの表現を一意に構築します。これは、すべての数が素数の一意の積であるため、簡単に解凍できます。これらのシーケンスを素数に関連付けるために、辞書を使用します。 私の質問は： 著者が示唆しているように、これは本当に実現可能ですか？論文によると、その結果は非常に効率的で、常にデータをより小さなサイズに圧縮します。辞書のサイズは膨大ではないでしょうか？ これを使用して、同じアルゴリズムを使用して圧縮データを繰り返し再圧縮することはできませんか？このような技術（圧縮データをできるだけ多く再圧縮し、ファイルサイズを劇的に削減する）は不可能であることは明らかであり、実証されています。実際、すべてのランダムデータのセットと圧縮データの間に全単射はありません。なぜこれが可能だと感じるのでしょうか？ 技術がまだ完全ではない場合でも、明らかに最適化および強力な改善が可能です。なぜこれは広く知られていません/研究されていないのですか？確かにこれらの主張と実験結果が真実であれば、これはコンピューティングに革命をもたらすことができなかったでしょうか？

22 information-theory  data-compression  primes 

コルモゴロフの複雑さについて何かを研究し、VitanyiとLiのいくつかの記事と本を読んで、正規化圧縮距離の概念を使用して著者のスティロメトリーを検証しました（各著者がどのようにテキストとグループ文書を書くかを類似性によって識別します）。 その場合、データコンプレッサーをチューリングマシンとして使用できるため、データコンプレッサーを使用してコルモゴロフの複雑さを近似しました。 データ圧縮とプログラミング言語（ある種のコンプレッサーを記述する）に加えて、コルモゴロフの複雑さを近似するために他に使用できるものはありますか？使用できる他のアプローチはありますか？

22 computability  approximation  data-compression  kolmogorov-complexity 

私はちょうど次のことを見つけました：png画像の複数の同一のコピーをフォルダに入れてから、次の方法でそのフォルダを圧縮しようとしました： tar czf folder.tar.gz folder/ tar cf folder.tar folder/ && xz --stdout folder.tar > folder.tar.xz （これは同一の画像ではうまく機能しますが、類似の画像ではゲインはゼロです） zip -r folder.zip folder/ 私はの大きさをチェックすると.tar.gz、.tar.xz、.zip私はそれはほとんどのものと同じであることに気づきましたfolder/。 png画像自体は高レベルの圧縮を行う可能性があるため、それ以上圧縮できないことを理解しています。ただし、多くの類似（この場合は同一）のpng画像をアーカイブにマージしてからアーカイブを圧縮すると、必要なサイズが著しく減少することが予想されます。同一の画像の場合、私はほぼ単一の画像のサイズのサイズを期待します。

21 data-compression 

この質問は、Computer Science Stack Exchangeで回答できるため、Stack Overflowから移行されました。 7年前に移行され ました。 任意のIDNホスト名（RFC5890で定義）のドメインを非常にコンパクトに圧縮する方法について興味があり、これが興味深い課題になると思われます。Unicodeホストまたはドメイン名（Uラベル）はUnicode文字の文字列で構成され、通常、トップレベルドメイン（たとえば、ギリシャ文字）に応じて1つの言語に制限され、（対応するラベル）。.grxn-- 正式な要件だけでなく、 各非Unicodeラベルは文字列一致^[a-z\d]([a-z\d\-]{0,61}[a-z\d])?$です; 各Aラベルは、一致する文字列^xn--[a-z\d]([a-z\d\-]{0,57}[a-z\d])?$です。そして ドメイン全体の長さ（Aラベルと '。'区切り文字で連結された非IDNラベル）が255文字を超えない 次のようなさまざまなヒューリスティックからも： 下位Uラベルは、固有名詞や数字（ハイフンを除く句読点、空白が取り除かれ、Nameprepごとに折り畳まれている）を含む一部の自然言語で、字句的、構文的、意味的に有効なフレーズであることが多く、短いフレーズが優先されます。そして 高次ラベルはSLDおよびTLDの辞書から引き出され、低次ラベルで使用される自然言語を予測するためのコンテキストを提供します。 こうした短い文字列を適切に圧縮することは、データのこれらの特定の機能を考慮せずに困難になること、さらに、既存のライブラリがより一般的なユースケースに対応するために不要なオーバーヘッドを生成することを恐れます。 Matt MahoneyのオンラインブックData Compression Explainedを読むと、上記の（および/または他の）モデリングの前提を活用するために多くの既存の手法を使用して、特定のツールよりもはるかに優れた圧縮を実現できることが明らかです。 コンテキストとして、この質問はSOに関する以前の質問からの派生物です。 最初の考え この問題はオフライントレーニングの優れた候補であり、次の行に沿って圧縮データ形式を想定しています。 「パブリックサフィックス」のハフマンコーディング。ドメイン登録またはトラフィックボリュームの公開されたソースから抽出された確率。 残りのUラベルに使用される（自然言語）モデルのハフマンコーディング。ドメインサフィックスのコンテキストを指定して、ドメイン登録またはトラフィックボリュームの公開されたソースから抽出された確率。 指定された自然言語モデルからいくつかの辞書ベースの変換を適用します。そして Uラベル内の各文字の算術コーディングと、オフライントレーニングから派生した文脈適応型自然言語モデルから得られる確率

21 algorithms  strings  natural-language-processing  data-compression 

順序付けられたペア（x、y）を順序付けられていないペア{x、y}（セット）と比較すると、理論的にはxは最初に来るかyが表現するために正確に1ビットを必要とするかの違いは1ビットだけです。 したがって、x、yが2つの異なる32ビット整数であるセット{x、y}が与えられた場合、それらを63ビット（64ではなく）にパックできますか？63ビットの結果から元の32ビット整数を復元できますが、順序を復元することはできません。

20 information-theory  data-compression 

シミュレートされたカードゲームに使用している実際のデータがあります。スーツではなく、カードのランクにのみ興味があります。ただし、標準のカードデッキであるため、このデッキでは各ランクのうちしか使用できません。デッキは各ハンドでうまくシャッフルされ、その後、デッキ全体をファイルに出力します。そのため、出力ファイルには、シンボルが個しかありません。（ = 10ランク）。したがって、もちろん、シンボルごとにビットを使用してこれらをビットパックできますが、可能なエンコードのうちを無駄にしています。一度にシンボルをグループ化してから圧縮すると、より良い結果が得られます。4 13 2 、3 、4 、5 、6 、7 、8 、9 、T 、J 、Q 、K 、A T 45252524441313132,3,4,5,6,7,8,9,T,J,Q,K,A2,3,4,5,6,7,8,9,T,J,Q,K,A2,3,4,5,6,7,8,9,T,J,Q,K,ATTT44416 4 13 433316161644413413413^4 =あり、代わりにビットにかなり「」収まることができます。理論的なビットパッキングの制限は、可能なカードごとにランダムシンボルを持つデータの場合、log（）/ log（）=です。しかし、このデッキには、たとえば王を置くことはできません。各デッキには各ランクがしかないため、エントロピーエンコーディングはシンボルごとに約0.5ビット、約低下します。28,56128,56128,5611515151616161313132223.700443.700443.700441313135252524443.23.23.2 わかりましたので、ここに私が考えていることです。このデータは完全にランダムではありません。枚のカード（シャッフルデッキと呼ばれる）の各ブロックには各ランクがあることがわかっているため、いくつかの仮定と最適化を行うことができます。そのうちの1つは、最後のカードをエンコードする必要はありません。何をすべきかがわかるからです。別の節約は、単一のランクで終了する場合です。たとえば、デッキの最後の枚のカードが場合、デコーダーはその時点までカードをカウントし、他のすべてのランクが満たされていることを確認し、を想定するため、それらをエンコードする必要はありません。行方不明」カードはすべてです。444525252333777777777333777 このサイトへの私の質問は、このタイプのデータでさらに小さな出力ファイルを得るために他にどのような最適化が可能か、そしてそれらを使用する場合、シンボルあたりビットの理論的な（単純な）ビットパッキングエントロピーを打ち負かすことはできますか、または平均でシンボルあたり約ビットの究極のエントロピー制限に近づきますか？もしそうなら、どのように？3.700443.700443.700443.23.23.2 ZIPタイプのプログラム（たとえばWinZip）を使用すると、圧縮のみが表示されます。これは、ビットに対して「遅延」ビットパックを実行しているだけであることがわかります。独自のビットパッキングを使用してデータを「事前圧縮」すると、zipプログラムで実行すると少し超える圧縮が行われるため、その方が良いようです。私が考えているのは、なぜ自分ですべての圧縮をしないのですか（Zipプログラムよりもデータの知識が豊富だからです）。log（）/ log（）=のエントロピー「制限」にことができるかどうか疑問に思っています。2:12:12:14442:12:12:11313132223.700443.700443.70044。私は、私が言及したいくつかの「トリック」と、おそらくさらに見つけることができるいくつかのトリックでできると思います。もちろん、出力ファイルは「人間が読める」ものである必要はありません。エンコーディングがロスレスである限り、有効です。 万の人間が読めるシャッフルデッキ（行にへのリンクを次に示します。誰でもこれらの行の小さなサブセットを「練習」してから、ファイル全体をリッピングできます。このデータに基づいて、最適な（最小の）ファイルサイズを更新し続けます。333111 https://drive.google.com/file/d/0BweDAVsuCEM1amhsNmFITnEwd2s/view ちなみに、このデータがどのタイプのカードゲームに使用されているかに興味がある場合は、ここに私のアクティブな質問へのリンクがあります（ポイントの賞金付き）。大量のデータストレージスペースが必要になるため、（厳密に）解決するのは難しい問題であると言われています。ただし、いくつかのシミュレーションはおおよその確率と一致しています。（まだ）純粋に数学的な解決策は提供されていません。難しすぎると思います。300300300 /math/1882705/probability-2-player-card-game-with-multiple-patterns-to-win-who-has-the-advant サンプルデータの最初のデッキをエンコードするためにビットを示す優れたアルゴリズムがあります。このデータは、Fisher-Yatesシャッフルアルゴリズムを使用してランダムに生成されました。それは本当のランダムデータなので、新しく作成されたアルゴリズムは非常にうまく機能しているようで、私は幸せです。168168168 圧縮の「チャレンジ」については、現在、デッキあたり約160ビットです。おそらく158まで下げることができると思います。はい、試しましたが、デッキあたり158.43ビットを得ました。アルゴリズムの限界に近づいていると思うので、デッキあたり166ビットを下回ることに成功しましたが、カードあたり3ビットである156ビットを取得できませんでしたが、楽しい練習でした。おそらく将来的には、各デッキを平均で2.43ビット以上削減する何かを考えます。

19 data-compression 

私はデータ圧縮アルゴリズムとデータ圧縮の理論的限界について読んでいました。最近、私は「コンビナトリアルエントロピーエンコーディング」と呼ばれる圧縮方法に出会いました。この方法の主なアイデアは、ファイルで表現される文字、その頻度、およびこれらの文字順列のインデックスとしてファイルをエンコードすることです。 これらのドキュメントは、この方法の説明に役立つ場合があります。 https://arxiv.org/pdf/1703.08127 http://www-video.eecs.berkeley.edu/papers/vdai/dcc2003.pdf https://www.thinkmind.org/download.php?articleid=ctrq_2014_2_10_70019 ただし、最初のドキュメントでは、この方法を使用して、シャノンの制限未満にテキストを圧縮できることを読みました（文字の頻度を保存するために必要なスペースとメタを保存するために必要なスペースを考慮しませんでした）ファイルのデータ）。私はそれについて考えましたが、この方法は非常に小さなファイルにはあま​​り効率的ではないことがわかりましたが、一方で、大きなファイルではうまく機能する可能性があります。実際、私はこのアルゴリズムやシャノンの限界を十分に理解していません。各文字の確率の合計に確率の逆数のを掛けたものだと知っています。L O G2log2log_2 だから私はいくつか質問があります： この圧縮方法は、実際にファイルをシャノンの制限よりも小さく圧縮しますか？ ファイルをシャノンの制限未満に圧縮する圧縮アルゴリズムはありますか（私が知る限り、この質問に対する答えはノーです）。 ファイルをシャノンの制限よりも小さく圧縮する圧縮方法はありますか？ コンビナトリアルエンコーディングが実際にシャノンの制限を超えてファイルを圧縮する場合、目的のファイルサイズに達するまで何度もファイルを圧縮することはできませんか？

17 information-theory  data-compression 

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ショー私には、この例では、この動作を説明できますか？

15 data-compression 

私たちが知っていることは、πは無限であり、可能性のあるすべての有限の数字列（論理和シーケンス）を含む可能性が非常に高いことです。 私は最近、作成したすべてのファイル（または他の誰か）または作成することを想定しているπfsのプロトタイプをいくつか見ました。それはすでにそこにあるので、それを抽出するだけです。ファイルをpiメタデータに変換できるpiFileもあります。 piのn番目の2進数を計算できるBBPタイプの数式が（実験数学の一部として）すでにあります。したがって、データの開始位置と長さを格納することで、理論的に関心のあるデータを抽出できます。メタデータ（データへのオフセットなど）が抽出されたデータよりも大きくなる可能性があるといういくつかの議論があります。マトリックスシンボルとπは、より効率的にするために、256でエンコードできます（ジョークを参照）。 上記に基づいて、私の主な質問は： PIに基づく圧縮アルゴリズムはありますか？ そうでない場合、それは意味がありますか？それともその分野での研究はありましたか？ あるいは、πは適切ではないかもしれませんが、オイラー定数またはタウ（τ）はどうでしょうか？何か違いはありますか？ 画像クレジット：恐竜コミック こちらもご覧ください： 有限のビット文字列は、妥当な時間内にpiで見つけることができますか？SOで インデックスをπに格納すると、元のデータと同じ大きさ（またはそれ以上）になりませんか？GitHubで

11 algorithms  data-compression  mathematical-programming