trie 实现中的空间差异答案

【问题标题】：Space differences in implementations of a trietrie 实现中的空间差异
【发布时间】：2013-01-21 18:56:41
【问题描述】：

我对尝试的了解越多，出于某种原因我就越感到困惑。
现在让我感到困惑的是：
我已经阅读了大约 2 种类型的实现。

使用数组表示字符（不存储字符本身）并且在每个节点中还存储实际单词的索引（如果我们达成了一个词）。
使用Collection 的节点存储字符并在末尾每个节点的使用布尔值来确定我们是否到达了一个单词沿着这条路走下去

在第一种情况下，它没有被提及，但似乎我们实际上必须保留所有字典单词（因为我们间接引用它们）。所以我们有array_size*numberOfNodes*lengthOfword + size of dictionary processed

在后一种情况下，我们不需要字典，因为字符直接存储在树中。所以在我看来，第二种实现更节省空间。但我不确定多少。
我对实现的理解是否正确，是否有特定的理由来选择另一种？另外我们如何计算第二种情况的空间需求？

【问题讨论】：

大多数为尝试显示的示例可以通过其他方式更有效地实现（维基百科示例，它使用散列字典提供字符查找，特别糟糕）。尝试提供明显胜利的地方是在更大规模的查找表中，例如，单个单词是节点键的查找表。它们还可以为稀疏表提供胜利。

标签： java string algorithm data-structures trie

【解决方案1】：

Tries 不会在任何地方存储原始单词，而是隐式存储它们。 trie的基本结构如下：trie中的每个节点都存储

确定到达节点的路径是否形成一个单词的单个位，并且
指向由字符标记的子节点的指针集合。

要确定一个单词是否在 trie 中，从根开始，然后按照适当标记的指针，一次一个。如果您到达标记为单词的节点，则该单词存在于 trie 中。如果你到达一个没有标记的节点或者你从树上掉下来了，那么这个词就不存在了。

您上面列出的两个结构之间的区别在于子指针的存储方式。在第一个版本中，子指针存储为字母表中每个符号一个指针的数组，这使得跟随子指针非常快，但空间效率极低。在第二个版本中，您显式存储某种类型的集合，其中仅包含您需要的标记指针。这速度较慢，但对于稀疏尝试而言更节省空间。

trie 的空间使用取决于节点的数量（称为 n）、字母表的大小（称为 k）以及子指针的表示方式。如果存储一个固定大小的指针数组，那么空间使用量约为 kn 个指针（n 个节点，每个节点有 k 个指针），加上每个节点处的标记的 n 位。例如，如果您有一个按排序顺序存储的动态指针数组，则开销将是 n 个子指针总数，加上 n 位，再加上存储单个集合所需的空间量的 n 倍。

第一种方法的优点是速度快且简单，在密集尝试中具有非常好的性能。对于稀疏尝试，第二个速度较慢但内存效率更高。

这些不是唯一可能的空间优化。 Patricia 尝试将只有一个子节点的节点压缩在一起，并且非常节省空间。 DAWG 尝试将尽可能多的节点合并在一起，但不支持高效插入。

希望这会有所帮助！

【讨论】：

1)实际单词中的索引怎么样？这种方法由 Sedgewick 提出。2)为什么第二种方法较慢？查找子项是否存在的集合的迭代是在一个常量大小的集合。字母大小。所以访问时间不是常量吗？3）我不知道你的意思是a dynamic array of pointers stored in sorted order,
1.我以前从未在 trie 中看到过单词索引；如果您想为每个节点存储辅助数据，这可能很有用，但肯定不是必需的。 2.虽然第二种方法也可以在常数时间内找到一个孩子，但它是一个更大的常数。您必须对一组指针进行二进制搜索或线性搜索才能找到所需的指针，而基于数组的版本需要单个间接。 3. 我建议您将子指针存储在动态分配的数组中，指针按它们使用的字符的升序排列。这有帮助吗？
@Cratylus- 见我上面的回复。
你的意思是保持集合中的字符排序？这不会增加插入时间吗？单词内的索引由 Sedgewick 提供。不确定他是否用这种方法解决了其他问题
@Cratylus- 这是一个保持排序的权衡 - 它减少了查找时间（二进制搜索），但确实增加了插入时间。没有一种“最佳方式”来实现 trie。一切都是一种权衡，只是哪种权衡最适合您的问题。