近似均匀数据的压缩算法
我在SE上看到过关于压缩算法的问题，但没有一个完全符合我的要求。显然，真正均匀分布的数据无法压缩，但我们能做到多近？
我（可能是错误的）想法：我会想象通过转换数据（以某种方式标准化？），您可以强调几乎一致的数据的非均匀性方面，然后使用转换集进行压缩，可能与逆变换或其参数一起进行。但也许我完全错了，当数据接近均匀性时，它们的表现都一样糟糕？
当我查看（无损）压缩算法列表时，我看不出它们对某些类型的数据有多有效，至少在任何具体方面没有。有人知道有人潜入这一领域吗？
作为背景，我有一个应用程序，其中数据集不是独立的，但似乎几乎是一致的（大多数符号具有非常低的频率，并且没有一个具有非常高的频率）。所以我想知道是否有算法可以利用采样依赖性，即使数据频率大多较低。当然，如果存在这样的情况，那么有一个详细说明为什么一些压缩算法在这方面可能比其他算法表现得更好的来源会更有帮助。
共有1个答案
简而言之，答案是否定的。这样的事情既不存在，也不可能存在。
冗长的答案涉及信息论。
对于压缩算法来说，重要的不是说出所指定的内容有多困难。它是指你可以说多少同样可能的事情，而不是。也就是说，如果你有同样可能说的事情，你必须发送一个足够长的信号，它指定你说的是哪一个。这需要log_2（M）位来明确你实际上说的是哪一个。
在一个独立符号流的情况下，每个符号都有一个已知的概率，我们可以计算出有多少消息可以以相同的可能性发送。从而为消息的压缩效率设定了下限。该下限是每个发送符号的熵位。这个下限实际上是通过哈夫曼编码实现的。
为了比哈夫曼编码做得更好，我们必须在消息中找到一些额外的结构。例如，语言通常具有相关性，其中“h”可能跟在“t”之后。或者在图像中，像素的颜色往往与附近像素的颜色相似。任何这样的结构都减少了我们本可以发送的同样可能的消息的数量，并为更好的压缩算法提供了可能性。
但是，您没有描述这样的结构。所以哈夫曼编码是你能做的最好的了。如果符号概率彼此接近，它不会给你太多。
很抱歉
-
问题内容： 在通过网络发送数据包之前压缩数据包的最佳压缩算法是什么？数据包使用JSON编码。LZW会是一个不错的选择吗？还是有更好的选择？ 问题答案： 我认为有两个问题会影响您的答案： 1）在不知道程序的任何特定运行情况下会如何预测数据的组成？例如，如果您的数据包如下所示： -那么您可能会通过创建一个不断出现在数据中的文本字符串的硬编码字典来获得最佳压缩，并用适当的字典索引替换每个出现的文本字符串
-
我想知道我们可以在多大程度上进行无损数据压缩；我无法找到一个无损算法的在线模拟器来执行一些经验测试。我可以自己做一个，但不幸的是，我在这段时间没有足够的时间；我仍然对我的直觉感到好奇，我将解释一下。 让我们只看两种更流行的算法：
-
我有9个ignite服务器实例，其缓存处于模式，在这种模式下，我用Kafka从分区并行加载数据。这里的分区包含的条目数可以通过字段唯一标识，我还使用将条目从一个分区配置到一个实例。我将key定义为， 因此，我试图在ignite实例中的缓存项和分区之间实现一对一的映射，例如。但在我的例子中，我得到的映射是， 这里实现了关联配置部分，即具有相同分区ID的条目缓存在相同的ignite实例上。但是，数据在
-
问题内容： 假设我要在2d矩形区域内插值。我的变量“ z”包含如下所示的数据。每列的值都是恒定的，但是，数组的每一行的值可以不同，如下面的注释所示。 作为另一种可视化方法，我知道的值数组为： 我不知道“？” 值，并且应该对其进行插值。我尝试将它们替换为“无”，但是所有结果都得到“ nan”。 编辑： 我想我需要使用’griddata’或’interp2’。griddata似乎产生了我期望的结果，但
-
0.1-0.2:********** 0.2-0.3:******** 0.3-0.4:********* 0.5-0.6:********* 0.6-0.7:********* 0.7-0.8:********* 0.4-0.5:********* 0.5-0.6:********* 0.6-0.7:********* 0.1-0.2:********* 0.2-0.3:********* 0.
-
问题内容： 我正在使用以下代码来压缩和解压缩字符串数据，但是我面临的问题是，它很容易被压缩而不会出错，但是decompress方法会引发以下错误。 线程“主”中的异常java.io.IOException：不是GZIP格式 仍然不知道如何解决此问题！！！ 问题答案： 这是因为 发送您可以从中获得的，并在其中使用它来构建您的。以下是需要在代码中进行的更改。