Questions tagged «encoding»

我正在寻找以下结果的参考： 在因式分解表示中添加两个整数与在通常的二进制表示形式中分解两个整数一样困难。 （我很确定它在那里，因为这是我在某个时候想知道的，然后当我终于看到它印刷时感到很兴奋。） 问题是“在因式表示形式中添加两个整数”：给定两个数和y的素数分解，输出x + y的素数分解。请注意，针对此问题的朴素算法在标准二进制表示形式中使用分解作为子例程。xxxyyyx+yx+yx+y 更新：感谢Kaveh和Sadeq的证明。显然，更多的证据可以证明是更好的选择，但是我也想鼓励人们在寻找参考文献时提供更多帮助，正如我所说的那样，我很确定存在。我记得在一篇论文中读到它时有其他有趣且很少讨论的想法，但我不记得那些其他想法是什么或论文的总体含义。

22 cc.complexity-theory  reference-request  time-complexity  factoring  encoding 

流行的DEFLATE算法在Lempel-Ziv的顶部使用霍夫曼编码。 通常，如果我们有一个随机的数据源（= 1位熵/位），那么包括霍夫曼在内的任何编码都不可能平均地对其进行压缩。如果Lempel-Ziv是“完美的”（随着长度的增长，它对于大多数类型的信号源都接近无穷大），那么用霍夫曼进行后期编码将无济于事。当然，Lempel-Ziv 并不完美，至少长度有限，因此仍然存在一些冗余。 霍夫曼编码部分地消除了这种剩余的冗余，从而改善了压缩。 我的问题是：为什么通过Huffman编码而不是LZ成功消除了剩余的冗余？霍夫曼与LZ的哪些属性使这种情况发生？再次运行LZ（即第二次使用LZ编码LZ压缩数据）是否会实现类似的效果？如果没有，为什么不呢？同样，首先使用Huffman进行压缩，然后使用LZ进行压缩，如果不能，为什么？ 更新： 很明显，即使在LZ之后，也会保留一些冗余。有几个人指出了这一点。尚不清楚的是：为什么霍夫曼要比LZ更好地解决剩余冗余问题？与原始的源冗余（LZ比Huffman更好）相比，它有什么独特之处？

13 ds.algorithms  it.information-theory  coding-theory  encoding 

很容易看出，对于任何，存在从{0,1}到{0,1}的1-1映射，使得对于任何，向量是“平衡的”，即它具有相等的1和0。是否可以定义这样的以便在给定我们可以 有效地计算？F n n + O （log n ） x F （x ）F x F （x ）nnnFFFnn^nn+O(logn)n+O(log⁡n)^{n+O(\log n)}xxxF(x)F(x)F(x)FFFxxxF(x)F(x)F(x) 谢谢。

10 ds.algorithms  ds.data-structures  encoding 

令为字母，即非空有限集。字符串是任何有限的元素（字符）序列。例如，是二进制字母，而是该字母的字符串。ΣΣ\SigmaΣΣ\Sigma{ 0 ，1 }{0,1} \{0, 1\}011001100110 通常情况下，只要包含超过1元，在元素的确切数字并不重要：在最好的，我们有不同的恒定地方结束。换句话说，我们使用二进制字母，数字，拉丁字母还是Unicode并不重要。ΣΣ\SigmaΣΣ\Sigma 在某些情况下，有多少字母是重要的情况？ 我对此感兴趣的原因是因为我偶然发现了一个这样的例子： 对于任何字母我们将随机预言定义为从返回随机元素的预言，这样每个元素都有相等的机会被返回（因此每个元素的机会都是）。ΣΣ\SigmaØΣOΣO_{\Sigma}ΣΣ\Sigma1个| Σ |1|Σ|\frac{1}{|\Sigma|} 对于某些字母和（可能具有不同的大小），请考虑可以访问的oracle计算机的类别。我们对此类中与行为相同的oracle计算机感兴趣。换句话说，我们想使用图灵机将oracle转换为oracle。我们将这种图灵机称为转换程序。Σ1个Σ1\Sigma_1Σ2Σ2\Sigma_2ØΣ1个OΣ1O_{\Sigma_1}ØΣ2OΣ2O_{\Sigma_2}ØΣ1个OΣ1O_{\Sigma_1}ØΣ2OΣ2O_{\Sigma_2} 令和。转换到Oracle很简单：我们查询两次，转换结果如下：，，，。显然，该程序运行时间为。Σ1个= { 0 ，1 }Σ1个={0，1个}\Sigma_1 = \{ 0, 1 \}Σ = { 0 ，1 ，2 ，3 }Σ={0，1个，2，3}\Sigma = \{ 0, 1, 2, 3 \}ØΣ1个ØΣ1个O_{\Sigma_1}ØΣ2ØΣ2O_{\Sigma_2}ØΣ1个ØΣ1个O_{\Sigma_1}00 → 000→000 \rightarrow 001 → 101→1个01 \rightarrow 110 → 210→210 \rightarrow 211 → …

9 big-list  encoding  examples