我遇到了这个问题;
“无损压缩算法声称可以保证一些文件更小，文件更大。” 是这个;
a）不可能
b）可能但可能会持续不确定的时间，
c）压缩系数2或更低可能，
d）可能出现任何压缩因素吗？“
我倾向于（a），但无法解释为什么。 （我会列出朋友和我想出的想法作为可能的答案）
答案 0 :(得分：14)
根据鸽子洞的原则，给定一个10位的字符串，你有1024个可能的输入，并且需要映射到9位或更少，所以有＆lt; 1024输出。
这可以保证算法具有冲突（有损压缩），或者在某些时候选择将未修改的输入作为输出返回。
在后一种情况下，您无法确定如何解压缩任意位串。 （它可以是未修改的输入，也可以是来自较大位串的压缩输出）。
- ＆GT;不可能。
答案 1 :(得分：9)
稍微澄清一下RJFalconer的帖子......
您只需要将某些文件变小，因此声称10位字符串必须映射到9位或更少的声明并不完全正确。特别是，如果有人提出了这样的压缩机制，它可以将所有10位或更少的字符串映射到完全相同的输出（即身份转换）。
但是，我们被告知至少有一个文件确实变小了。不失一般性，考虑从x位开始并以y位结束，其中y严格小于x。
现在考虑“具有y位或更少的文件”的域，其具有2个 y + 1 -1位串（包括空位）。为了不使这些文件产生更大的文件，每个文件必须映射到同一域中的位串，即2个 y + 1 -1个压缩文件。但是，我们已经知道长度为x位的初始字符串会压缩到其中一个值 - 只留下2个 y + 1 -2个可能的值。
在这个点，鸽子洞的原理出现了 - 你显然无法将2 y + 1 -1输入映射到2 y + 1 -2输出而不重复输出，这违反了压缩的可逆性。
答案 2 :(得分：0)
a）不可能
如果你有一个无法进一步压缩的文件，你仍然需要添加它是否已被压缩的信息，因此在这种情况下文件必须增长。
答案 3 :(得分：0)
我知道我有点迟了，但我通过谷歌找到了这个，其他人也可以这样做，所以我会发布我的回答：显而易见的解决方案是a) impossible，Jon也指出了这一点。 Skeet（顺便说一句，互联网上有很多证据）。我不是在质疑压缩随机数据的不可能性，只是从一开始就要明确;我理解了它背后的理论，如果你问我 - 我相信数学。 ：D
但是，如果我们被允许think laterally，我们肯定可以利用这个问题没有明确定义的事实，这意味着它没有给出“压缩算法”的严格定义，它应具有的属性（但是为了减少某些文件而不扩展其他任何人）。
此外，它没有对要压缩的文件施加任何条件，它唯一感兴趣的是“使一些文件变小而没有更大的文件”。
那就是说，我们现在至少有两种方式来证明，事实上它确实存在这样一种算法：
我们可以利用文件的名称来存储文件的一些信息（甚至整个文件，如果文件系统允许的话，那么将每个文件减少到0位）。 平凡的是，我们可以简单地决定保留每个文件而不是一个，将其减少到0位并用预定义的名称重命名。 我同意这可以被认为是作弊，但是再一次，初始问题没有限制，这个算法将有效地达到目的（只要没有人重命名文件，这就是为什么这将是一个非常糟糕的设计选择除了没有意义）。
我们可以将要压缩的文件数限制为至少X位长的文件。再一次，一个简单的解决方案是将每个文件保持不变，但是我们可以减少使其与小于X位的文件匹配。
现在我们有一个算法，它逐字引用，使一些文件更小，文件更大;但是，它对所有可能的输入执行限制（即它无法处理所有文件）。
对于那些认为这没有任何实际用途的人，我说我同意你的意见......但是，嘿，这是理论，这只是一篇理论论文。 ;）
显然，如果我要做一个测试并面对这个问题，我会在a)上加上一个大胆的X，然后继续下去，不要过多考虑它。
尽管如此，完全有可能表明，由于自然语言本质上含糊不清并且问题没有正式表达，其他每个可能的答案都不一定是错误的：放置正确的条件并最终明确指出什么意思通过某些概念，我们可以合法地满足任何其他列出的选项的目标，做某种诡计并迫使程序实现所期望的行为。
答案 4 :(得分：0)
e）可能的
......有一些限制。
我最近遇到了Shoco，一个用于小字符串的字符串压缩库。在阅读这个说法时我被提醒了这个问题：
... shoco最显着的特性是压缩大小永远不会超过输入字符串的大小，只要它是纯ASCII。
如果您确定输入数据是纯ASCII，那么您的输出缓冲区只需要与输入字符串一样大
答案 5 :(得分：0)
可能
to make some files smaller and no files larger
如果所述压缩算法使文件更大，则使其返回原始文件。