我们知道π是无限的，并且很可能包含每个可能的有限数字串（析取序列）。

我最近看到了一些πfs原型，它假定您已经创建（或其他任何人）或将要创建的每个文件，该文件已经存在，因此只需提取它即可。还有piFile可以将您的文件转换为pi元数据。

已经存在BBP类型公式（作为实验数学的一部分），它使我们能够计算pi的第n个二进制数字。因此，存储我们的起始位置和数据长度，从理论上讲，我们可以提取我们感兴趣的数据。有一些反对意见认为，我们的元数据（例如，数据的偏移量）可能大于提取的数据。矩阵符号和π可以在base-256中编码，以使其效率更高（请参阅笑话）。

基于上述，我的主要问题是：

• 是否有基于PI的压缩算法？

如果没有，那有意义吗？还是在那个领域有研究？

也许π不是正确的，那么欧拉常数或Tau（τ）呢？有什么不同吗？

^{图片来源：恐龙漫画}

也可以看看：

• 可以在合理的时间内在pi中找到任何有限位字符串吗？在SO
• 将索引存储到π中会不会与原始数据一样大（或更大）？在GitHub

由于许多原因，您的建议没有多大意义。首先，当尝试压缩一个大文件（例如一个字节大小的文件）时，您将不得不在二进制扩展名中找到一个与文件相符的位置。由于该文件的长度为位，因此可以预期该位置在第位附近。因此，很难找到它。这不仅是因为我们必须进一步扩展，还因为我们希望在找到成功之前尝试不同的位置。π 128 2 128 2 $16$$\pi$$128$$2^{128}$$2^{128}$

其次，尽管在某些情况下，您的方案将导致重大压缩，但这仅在某个字符串在扩展的早期出现时才会发生。您没有理由要压缩那种字符串。相反，其他压缩算法尝试在数据中查找结构，并保证表明如果存在这样的结构，则它们总是可以利用它。$\pi$

用其他任何数字更改都不会改变图片。该算法过于具体，仅压缩我们并不真正感兴趣的字符串。并且在压缩阶段效率很低。$\pi$

根据Yuval的回答，稍有不同的解释和示例来说明问题。

理论

取一个字节长（位）的文件。压缩算法如下：$16$$128$

1. 确定的二进制扩展名与内容匹配的位置。$\pi$
2. 存储偏移量和已排序的位数（）。$128$

对于该文件的内容应该是周围的偏移^个位; 但是，找到偏移量很耗时，因为它需要：$2^{128}$

• 深入搜索位模式；和
• （平均）查看不同的位置。$2^{128}$

在中发生得较早以达到明显压缩的匹配将不会改变。也就是说，不可能使用压缩有趣的真实数据，因为真实单词字符串不太可能早出现。$\pi$$\pi$

另请参阅信息熵。

例

让我们压缩一个社会安全号码（SSN）：938-933-556。使用计算要对该值编码的位数，该位数约为并且必须四舍五入为（因为位数不可分割）。29.8 $log_2(938933556)$$29.8$$30$

在，该SSN开始于偏移，需要的比特，或〜，并且必须也被舍入到。偏移可能更早，但是不太可能需要更少的位。597 ，507 ，393 升Ô 克2（597507393 ）29.2 $\pi$$597,507,393$$log_2(597507393)$$29.2$$30$

也许我们可以对数字进行分块？

• 938，偏移位$1,124$
• 933，偏移位$1,216$
• 556，偏移量位$11,727$

那是位，甚至更糟。也许是不同的分块？$36$

• 9,389,335，偏移量位$15,312,393$
• 6，偏移位$8$

那是位，好于，但是有问题。首先，添加非均匀分块需要更多信息以指示分块在何处开始和停止。其次，找到最佳的分块以获取最少的位会花费更多的时间。第三，保存三位几乎不算压缩。$27$$30$

不同的先验数或多或少将具有相同的统计结果。即使您剃掉一根头发，例如，剃掉了两块钱，也必须指出使用的常数。三位允许算法从八个不同数字之一中进行选择。结果，由于搜索序列而不是一个序列，该算法将慢得多。$N$

是否有基于PI的压缩算法？

是的，https：//github.com/divinity76/pi_compression

是否有意义？

不会，至少在上述实现中，存储偏移量通常会比您节省的磁盘空间更多（尽管有3处值得注意的地方可以改进，它仅考虑pi二进制表示形式的前2 ^ 32个字节，并且使用过多的位来存储每个偏移量的匹配字节数，即8位，而测试表明3位是最佳选择，并且仅考虑全字节匹配，因此，如果某处有15位匹配，它将仅被视为8位匹配。.如果字节的最后4位匹配但不匹配＃3，而下一个字节的前4位匹配但不匹配＃5，则不视为匹配所有）

还是在那个领域有研究？

嗯，这就是我编写上述实现的原因，结果似乎是在pi的前4GB中，您可能会找到4个匹配的字节。几乎所有内容，这都是非常困难的，即使不是不可能，为了获得任何压缩，我至少失败了。（但是如上所述，我的实现不是最佳的）-压缩速度也很慢，但是我的实现是单线程的，但是如果有人对编写代码感到厌倦，该算法允许使用多线程，从而可以扩展性能。可用核心数。

减压非常快​​。

是否有基于PI的压缩算法？

这个问题似乎是由一些“流行科学” 推测引起的，即或其他数学常数包含所有可能的数字序列，但未经证实。基于具有任意数字序列的压缩算法不是不可想象的，而是取决于以下特性。即“ afaik”是一个开放的问题/问题，以下问题是否可确定（其他经典常量也是如此）：$\pi$$\pi$

输入序列。输出，Y / N，包含序列π $X$$\pi$$X$

没有基于 “主流”压缩算法，但是在（T）CS中，围绕“主流”划出严格的边界非常困难/成问题。与该术语的常用用法相反，它指的是一组“广泛使用”或“标准”算法，CS中的“压缩算法”是一个非常广泛的概念。从技术上讲，是的，“ 存在一种基于的压缩算法”，因为它很容易构造一个“人为的”（供读者练习），但是，没有，没有标准的算法是基于数学常数中的数字序列。$\pi$$\pi$

即使显示出任何数学常数都具有“包含所有字符串”的显着特性，一个简单的论点是压缩算法将花费“太多时间”来搜索字符串的位置，并且描述其位置通常会花费一个时间。一长串数字。

另请参见/对比/尝试与类似的高票问题调和如何确定pi是否包含一些数字序列。（cs.se）（提示：标题可能会被误导）