Questions tagged «data-compression»

很久以前，我读过一篇报纸上的文章，其中一位教授说，将来我们将能够将数据压缩到仅两位（或类似的东西）。 这当然是不正确的（可能是我对他确切说的话的记忆是不正确的）。可以理解的是，将0和1的任何字符串压缩为两位都是不切实际的，因为（即使在技术上可行），太多不同种类的字符串最终会压缩为相同的两位（因为我们只有'01 '和'10'可供选择）。 无论如何，这让我想到了根据某种方案压缩任意长度的0和1的字符串的可行性。对于这种字符串，字符串长度（0与1之间的比率可能无关紧要）与最大压缩之间是否存在已知关系？ 换句话说，有没有一种方法可以确定可压缩为0和1的字符串的最小（最小）长度？ （在这里，我对数学上的最大压缩感兴趣，而不是当前在技术上可能实现的最大压缩。）

38 data-compression 

这个想法是我小时候学习编程的想法，并且是第一次接触PRNG。我仍然不知道它有多现实，但是现在有了堆栈交换。 这是14岁的人使用的一种出色的压缩算法方案： 取一个PRNG并用种子s进行种子处理，以获得长序列的伪随机字节。要将序列发送给另一方，您只需要传达PRNG的说明，适当的种子和消息的长度。对于足够长的序列，该描述将比序列本身短得多。 现在，假设我可以反转该过程。如果有足够的时间和计算资源，我可以进行蛮力搜索，找到可以产生所需序列的种子（和PRNG，或者换句话说：一个程序）（比方说，一张有趣的猫调皮的照片）。 在生成足够多的比特之后，PRNG会重复，但是与“典型”周期相比，我的消息非常短，因此这似乎不是一个很大的问题。 Voila，一种有效的压缩数据方式（如果是rube-Goldbergian）。 因此，假设： 我希望压缩的序列是有限的，并且事先知道。 我的现金或时间并不短缺（只要两者都需要有限的金额） 我想知道： 该计划背后的推理是否存在根本缺陷？ 分析这类思想实验的标准方法是什么？ 摘要 通常，好的答案不仅可以弄清楚答案，而且可以弄清楚我真正要问的是什么。感谢大家的耐心配合和详细的答案。 这是我对答案的第n次尝试： PRNG /种子角度没有任何作用，只不过是生成所需序列作为输出的程序。 信鸽原理：长度大于k的消息比长度小于等于k的（消息生成）程序多。因此，某些序列根本不能成为比消息短的程序输出。 值得一提的是，程序（消息）的解释程序必须事先确定。它的设计确定了接收到长度为k的消息时可以生成的（小）消息子集。 至此，原始的PRNG想法已经死了，但是至少还有一个最后的问题需要解决： 问：我能幸运地发现我的长（但有限）消息恰好是长度小于k位的程序的输出吗？ 严格来说，这不是偶然的问题，因为必须事先知道所有可能的消息（程序）的含义。要么是 <k位的一些信息的含义或它不是。 如果我随机选择一个随机消息，该消息>> k位（为什么？），无论如何我都将拥有使用少于k位发送消息的可能性，并且几乎可以肯定无法发送它完全使用不到k位。 OTOH，如果我从少于k位的程序输出中选择大于等于k位的特定消息（假设有这样的消息），那么实际上我是在利用已经传输到接收方（解释程序的设计），它被视为已传输消息的一部分。 最后： 问：熵 / kolmogorov复杂度业务到底是什么？ 最终，两者都告诉我们与（简单的）信鸽原理告诉我们的一样，我们可以压缩的程度：也许一点也没有，也许有些，但是肯定不如我们想象的那么多（除非我们作弊）。

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

根据维基百科： 香农的熵衡量的是消息中包含的信息，而不是确定的（或可预测的）消息部分。后者的示例包括语言结构的冗余或与字母或单词对，三胞胎等的出现频率有关的统计属性。 因此，熵是对消息中包含的信息量的度量。熵编码器用于将此类消息无损压缩到表示该消息所需的最小位数（熵）。对我来说，这似乎是一个完美的熵编码器，它是尽可能无损压缩消息所需的全部。 然而，许多压缩算法在熵编码之前使用步骤以减少消息的熵。 根据德国维基百科 Entropiekodierer werdenhäufigmit anderen Kodierern kombiniert。大律师，大律师，大律师和大律师。 用英语： 熵编码器经常与其他编码器结合使用。前面的步骤用于减少数据的熵。 即bzip2在应用熵编码（在这种情况下为霍夫曼编码）之前先使用Burrows-Wheeler-Transform，然后再进行Move-To-Front-Transform。 这些步骤是否真的减少了消息的熵，这意味着减少了消息中包含的信息量？这在我看来是矛盾的，因为那将意味着在压缩过程中信息丢失，从而阻止了无损解压缩。还是仅转换消息以提高熵编码算法的效率？还是熵不直接对应于消息中的信息量？

35 information-theory  data-compression  entropy 

我想枚举所有大小为无向图，但是我只需要每个同构类的一个实例。换句话说，我想枚举个顶点上的所有非同构（无向）图。我怎样才能做到这一点？nnnnnn 更准确地说，我想要一种算法，该算法将生成具有以下特性的无向图的序列：对于个顶点上的每个无向图，都存在一个索引，使得与同构。我希望该算法尽可能高效。换句话说，我关心的指标是生成和迭代此图列表的运行时间。第二个目标是，如果算法不太复杂而无法实现，那就太好了。G1,G2,…,GkG1,G2,…,GkG_1,G_2,\dots,G_kGGGnnniiiGGGGiGiG_i 请注意，每个同构类至少需要有一个图，但是如果该算法产生多个实例，则可以。特别是，如果输出序列包含两个同构图，则可以，只要这可以帮助您更轻松地找到这样的算法或启用更有效的算法，只要它覆盖所有可能的图即可。 我的应用程序如下：我有一个程序要在大小为所有图形上进行测试。我知道如果两个图是同构的，则我的程序将在两个同构上表现相同（对两个图都正确，或者对两个图都不正确），因此足以枚举每个同构类的至少一个代表，然后对其进行测试。对这些输入进行编程。在我的应用程序中，很小。nnnnnn 我考虑过一些候选算法： 我可以列举所有可能的邻接矩阵，即所有对称的 0或1矩阵，对角线都为0。但是，这需要枚举矩阵。这些矩阵中有许多将表示同构图，因此这似乎在浪费大量精力。n×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 − 10002n−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程序而创建的真正的熵源吗？不是统一分布的随机数生成器，而是一个的熵源？由在物理硬件上运行的软件构建的熵源，恰好是PC。 补充性 为了确认每个图像都产生新的熵，而没有所有人共有的固定模式，生成了10个连续图像。然后将它们连接起来，并使用我可以编译的最强大的存档器（paq8px）进行压缩。此过程将消除所有通用数据，包括自动关联，仅保留更改/熵。 串联文件被压缩到〜66％，这导致〜5.3位/字节或10.5Mbits /图像的熵率。令人惊讶的熵⌣⌣ \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 Estimate …

25 randomness  data-compression  entropy  random-number-generator 

我最近偶然发现了以下有趣的文章，该文章声称无论数据的类型和格式如何，始终有效地将随机数据集压缩超过50％。 基本上，它使用质数唯一地构造4字节数据块的表示形式，由于每个数字都是质数的唯一乘积，因此易于解压缩。为了使这些序列与质数相关联，它利用字典。 我的问题是： 正如作者建议的那样，这真的可行吗？根据该论文，它们的结果非常有效，并且始终将数据压缩为较小的大小。字典的大小会不会很大？ 难道不能使用同一算法来迭代地重新压缩压缩数据吗？很明显，并且已经证明，这种技术（压缩的数据被尽可能多地重新压缩，从而大大减小了文件的大小）是不可能的。实际上，在所有随机数据的集合和压缩数据之间不会存在双射。那么为什么会有这种感觉呢？ 即使该技术尚不完善，也显然可以对其进行优化和大力改进。为什么没有对此进行更广泛的了解/研究？如果确实这些主张和实验结果是正确的，那么这将不会给计算带来革命性的变化？

22 information-theory  data-compression  primes 

我研究了有关Kolmogorov复杂性的内容，阅读了Vitanyi和Li的一些文章和书籍，并使用归一化压缩距离的概念来验证作者的脚步法（通过它们的相似性来确定每个作者如何写一些文本和组文档）。 在那种情况下，由于数据压缩器可以用作图灵机，因此使用数据压缩器来近似Kolmogorov复杂度。 除了数据压缩和编程语言（您将使用其中编写某种压缩器）之外，还可以使用其他什么方法来近似Kolmogorov复杂度？还有其他方法可以使用吗？

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 

此问题是从Stack Overflow 迁移而来的，因为可以在Computer Science Stack Exchange上回答。 迁移 7年前。 我对如何紧凑压缩任意IDN主机名（由RFC5890定义）的域感到好奇，并怀疑这可能会成为一个有趣的挑战。Unicode主机或域名（U标签）由一串Unicode字符组成，通常取决于顶级域名（例如，下的希腊字母.gr），被限制为一种语言，该Unicode字符被编码为以xn--（一个标签）。 人们不仅可以根据以下正式要求来建立数据模型： 每个非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都需要一个单独的位来表示。 因此，如果给定集合{x，y}，其中x，y是两个不同的32位整数，是否可以将它们打包为63位（而不是64位）？应该可以从63位结果中恢复原始的32位整数，但不能恢复其顺序。

20 information-theory  data-compression 

我有用于模拟纸牌游戏的真实数据。我只对卡片的等级感兴趣，对西服不感兴趣。但是，它是标准的张纸牌，因此该纸牌中每个等级只能有张纸牌。每副牌的洗牌盘都洗好了，然后我将整个唱盘输出到一个文件中。因此，在输出文件中只有可能的符号分别是。（ =十位）。因此，我们当然可以使用每个符号位对它们进行位打包，但是随后我们浪费了可能编码中的种。如果一次将符号分组，然后对其进行压缩，则可以做得更好，因为28 ，561 15 16 13 2 3.70044 13 52 4 3.252525213 2 ，3 ，4 ，5 ，6 ，7 ，8 ，9 ，4441313132,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,ATTT44433316161644413413413^4 =，可以“ ”放入位而不是位。对于每个可能的卡，带有随机符号的数据的理论位打包限制为log（）/ log（）=。但是，例如在此甲板中不能有国王。在每个套牌中，每个等级必须只有，因此熵编码每个符号下降约一半，降至约。28,56128,56128,5611515151616161313132223.700443.700443.700441313135252524443.23.23.2 好的，这就是我的想法。此数据不是完全随机的。我们知道每个等级有，因此在张卡片的每块中（称为洗牌后的卡片组），因此我们可以进行几个假设和优化。其中之一就是我们不必对最后一张卡进行编码，因为我们会知道它应该是什么。如果我们只停留在一个等级上，那将是另一个节省。例如，如果最后在甲板卡是，我们不会有编码的，因为解码器将票卡到这一点，并看到所有其他的队伍已经排满，并且将承担 “ “失踪”卡全为 s。444525252333777777777333777 因此，我对此站点的问题是，在这种类型的数据上可以获得什至更小的输出文件还有哪些其他优化方法？如果使用它们，我们能否击败每个符号位的理论（简单）位打包熵，或者甚至接近每个符号平均约位的极限熵极限？如果是这样，怎么办？3.700443.700443.700443.23.23.2 当我使用ZIP类型的程序（例如WinZip）时，我只会看到2:12:12:1压缩，这告诉我它只是在将“惰性” 位打包为444位。如果我使用自己的位打包来“预压缩”数据，那似乎会更好，因为当我通过zip程序运行数据时，我得到的压缩比是2:12:12:1。我在想的是，为什么不自己进行所有压缩（因为我比Zip程序对数据有更多的了解）。我想知道是否可以克服 log（131313）/ log（222）= 3.70044的熵“极限”3.700443.700443.70044。我怀疑我可以通过我提到的一些“技巧”来发现更多的技巧。当然，输出文件不必是“人类可读的”。只要编码是无损的，它就是有效的。 这是333百万条人类可读混洗牌组（每行111条）的链接。任何人都可以“练习”这些行的一小部分，然后再将其撕裂整个文件。我将根据此数据继续更新最佳（最小）文件大小。 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位以下，但未能获得156位，即每张卡3位，但这是一个有趣的练习。也许在将来，我会考虑采取一些措施将每个卡座平均减少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 但是，在第一个文档中，我读到了通过使用这种方法，他们可以将某些文本压缩到小于Shannon限制（他们没有考虑节省字符频率所需的空间和节省元数据所需的空间。文件的数据）。我考虑了一下，发现这种方法对很小的文件不是很有效，但另一方面，它对于大文件可能很好用。实际上，我对这个算法或Shannon限制并不十分了解，我只知道它是每个字符的概率之和乘以概率的倒数的。log2log2log_2 所以我有一些问题： 这种压缩方法是否真的将文件压缩到小于Shannon限制？ 是否有任何压缩算法将文件压缩到小于Shannon限制（据我所知，对这个问题的回答是“否”）？ 是否存在将文件压缩到小于Shannon限制的压缩方法？ 如果组合编码确实压缩了超出Shannon限制的文件，难道不能一次又一次地压缩文件，直到达到所需的文件大小？

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” s的收支平衡（压缩比= 1）。图表开始时非常平稳，并且突然以98“ a”的速度渐渐前移，并从此逐渐变小。 局部低点和平滑部分似乎也很不稳定和随机。有人可以向我解释为什么bzip2在此示例中显示此行为吗？

15 data-compression 

我们知道π是无限的，并且很可能包含每个可能的有限数字串（析取序列）。 我最近看到了一些πfs原型，它假定您已经创建（或其他任何人）或将要创建的每个文件，该文件已经存在，因此只需提取它即可。还有piFile可以将您的文件转换为pi元数据。 已经存在BBP类型公式（作为实验数学的一部分），它使我们能够计算pi的第n个二进制数字。因此，存储我们的起始位置和数据长度，从理论上讲，我们可以提取我们感兴趣的数据。有一些反对意见认为，我们的元数据（例如，数据的偏移量）可能大于提取的数据。矩阵符号和π可以在base-256中编码，以使其效率更高（请参阅笑话）。 基于上述，我的主要问题是： 是否有基于PI的压缩算法？ 如果没有，那有意义吗？还是在那个领域有研究？ 也许π不是正确的，那么欧拉常数或Tau（τ）呢？有什么不同吗？ 图片来源：恐龙漫画 也可以看看： 可以在合理的时间内在pi中找到任何有限位字符串吗？在SO 将索引存储到π中会不会与原始数据一样大（或更大）？在GitHub

11 algorithms  data-compression  mathematical-programming