算法的大 O 复杂性 - LZW 和 Huffman答案

【问题标题】：Big O complexities of algorithms - LZW and Huffman算法的大 O 复杂性 - LZW 和 Huffman
【发布时间】：2011-09-05 14:16:49
【问题描述】：

在大 O 表示法中，Lempel-Ziv-Welch 和 Huffman 压缩算法的空间和时间复杂度是多少？ Google 让我失望了。

谢谢，

弗朗西斯科

【问题讨论】：

【解决方案1】：

由于字典大小是固定的并且与输入长度无关，LZW 在 O(n) 中，因为每个字节只读取一次，并且每个字符的操作复杂度是恒定的.

而Huffman encoding 也在 O(n) 中：首先计算每个输入字节的出现次数，然后对其进行排序并构建输出编码。

【讨论】：

【解决方案2】：

取决于实施。他们一直在变得更好。 “霍夫曼”这个词有点太常见了。例如，您可能指的是显式树、隐式树、动态树…… 但无论如何，我想如果你这样做非常聪明，你应该能够在O(n)上实现几乎任何“霍夫曼”，n 是文本长度。

LZW 也依赖于实现。我不知道“O”常见实现有什么。我猜对于大表，你可能有类似 O(n log n) 的东西，但这只是一个猜测。

【讨论】：

LZW 压缩字典有树字符。如果相应地存储，字典可以每个输入字节遍历一个节点，本质上使压缩算法 O(n) 时间基于输入长度。以这种方式存储字典可能会浪费大量内存，因此这是通常的速度-空间权衡，并且内存高效的实现可能至少为 O(n log n)，正如您所提到的。
O(n) 超过输入长度？这棵树会长到多大？超过 O(n)？不可能，因为要写一棵比 O(n) 更大的树，你还需要更多的 O(n) 时间。因此，为什么这个 O(n) 字典会浪费空间？ O(n) 听起来非常理想。假设字典需要让我们说每个输入字符 10 个字节是很多内存，但如果它值得......因此我的问题：它真的是 O(n) 吗？
考虑到新的输入值，问题是从一个节点到下一个节点。让那部分成为 O(1) 是诀窍。而且我怀疑如果不让每个树节点像哈希表一样工作或简单地拥有一个长度等于字母大小的数组，这很容易实现。哈希表仍然可以是 O(1)，但仍然存在那个臭名昭著的常数因素以及可能不得不增长表的开销。顺便说一句：如果你允许树无限增长，它的节点数将等于输入长度。
@Wormbo：啊，这就是你的意思。除此之外还有技巧。 Enhanced Suffix Arrays 是我知道的一个例子，我相信这也可以（并且可能）适用于 LZW。