私たちが知っていることは、πは無限であり、可能性のあるすべての有限の数字列（論理和シーケンス）を含む可能性が非常に高いことです。

私は最近、作成したすべてのファイル（または他の誰か）または作成することを想定しているπfsのプロトタイプをいくつか見ました。それはすでにそこにあるので、それを抽出するだけです。ファイルをpiメタデータに変換できるpiFileもあります。

piのn番目の2進数を計算できるBBPタイプの数式が（実験数学の一部として）すでにあります。したがって、データの開始位置と長さを格納することで、理論的に関心のあるデータを抽出できます。メタデータ（データへのオフセットなど）が抽出されたデータよりも大きくなる可能性があるといういくつかの議論があります。マトリックスシンボルとπは、より効率的にするために、256でエンコードできます（ジョークを参照）。

上記に基づいて、私の主な質問は：

• PIに基づく圧縮アルゴリズムはありますか？

そうでない場合、それは意味がありますか？それともその分野での研究はありましたか？

あるいは、πは適切ではないかもしれませんが、オイラー定数またはタウ（τ）はどうでしょうか？何か違いはありますか？

^{画像クレジット：恐竜コミック}

こちらもご覧ください：

• 有限のビット文字列は、妥当な時間内にpiで見つけることができますか？SOで
• インデックスをπに格納すると、元のデータと同じ大きさ（またはそれ以上）になりませんか？GitHubで

$16$$\pi$$128$$2^{128}$$2^{128}$

$\pi$

$\pi$

Yuvalの回答に基づき、少し異なる説明と問題を明らかにするための例を示します。

理論

$16$$128$

1. $\pi$
2. $128$

$2^{128}$

• ビットパターンのディープサーチ。そして
• $2^{128}$

$\pi$$\pi$

情報エントロピーも参照してください。

例

$log_2(938933556)$$29.8$$30$

$\pi$$597,507,393$$log_2(597507393)$$29.2$$30$

たぶん、私たちは数をチャンクできますか？

• $1,124$
• $1,216$
• $11,727$

$36$

• $15,312,393$
• $8$

$27$$30$

$N$

PIに基づく圧縮アルゴリズムはありますか？

うん、https：//github.com/divinity76/pi_compression

それは意味がありますか？

いいえ、オフセットの保存には、通常、少なくとも上記の実装では、節約するよりも多くのディスク領域が必要です（ただし、改善できる3つの注目すべき点は、piのバイナリ表現の最初の2 ^ 32バイトのみを考慮し、テストでは3ビットが最適であり、全バイト一致のみが考慮されるため、オフセットごとに一致するバイト数、つまり8ビットを格納するために過度のビットを使用します。したがって、どこかに15ビットの一致がある場合、 8ビット一致とのみ見なされます。また、バイトの最後の4ビットは一致するがビット＃3は一致せ​​ず、次のバイトの最初の4ビットは一致するがビット＃5は一致しない場合、一致とは見なされません。すべて）

それともその分野での研究はありましたか？

ええと、それが私が上記の実装を作成した理由であり、結果はpiの最初の4GB内で、一致する4バイトを見つける可能性が高いと思われます。圧縮を得るには、少なくとも失敗しました。（しかし、上記で説明したように、私の実装は最適ではありません）-また、圧縮は非常に遅いですが、私の実装はシングルスレッドですが、誰かがコードを書いていた場合にアルゴリズムでマルチスレッドが可能になり、パフォーマンスのスケーリングが可能になります利用可能なコアの数。

ただし、解凍は非常に高速です。

PIに基づく圧縮アルゴリズムはありますか？

$\pi$$\pi$

$X$$\pi$$X$

$\pi$$\pi$

数学定数が「すべての文字列を含む」という驚くべき特性を持っていることが示されていても、単純な議論は、圧縮アルゴリズムが文字列の位置を検索するのに「あまりにも多くの時間」を費やし、その位置を記述するのにしばしば時間がかかるということです。数字の長い（より長い）文字列。

コントラスト/で調整してみてください/も参照同様の高投票質問piは数字のいくつかの列が含まれているかどうか、それは決定可能であることができる方法を。（cs.se）（ヒント：タイトルはやや誤解を招くものと見なすことができます）