3

我知道如果我有均匀分布的整数键或可以映射到均匀分布的整数的键,我可以简单地将桶数组用于关联容器。如果我可以创建足够大的数组以确保某个负载因子(假设集合不是太动态),那么键的预期冲突次数将是有限的,因为这只是具有身份哈希函数的哈希表。

编辑:我认为字符串等同于 [0..1] 范围内的位置分数。因此,它们可以通过乘法和取结果映射到任何整数范围。

我也可以有效地进行前缀查询,就像尝试一样。我假设(不知道证明)与给定前缀相对应的空槽的预期数量必须在到达具有至少一个元素的第一个桶之前按顺序跳过也将受到常数的限制(再次取决于选择的负载系数)。

当然,我可以在最坏情况下的常数时间内进行 stabbing 查询,并在仅输出敏感的线性预期时间的范围内查询(如果上一段中的密集猜想确实是真的)。

那么尝试的好处是什么?

如果分布是均匀的,我看不到任何尝试做得更好的东西。但我可能错了。

如果分布具有较大的未补偿偏斜(因为我们没有先验概率或仅查看最坏情况),则桶数组的性能很差,但尝试也会变得严重不平衡,并且可以在任意长度的字符串中具有线性的最坏情况性能。因此,对您的数据使用任何一种结构都是值得怀疑的。

所以我的问题是 -在可以正式证明的桶数组上尝试的性能优势是什么?什么样的分布会带来这些优势?

我正在考虑在不同尺度上具有自相似结构的分布。我相信那些被称为分形分布,我承认对此一无所知。可能是这样,如果分布倾向于在每个规模上聚集,尝试可以提供卓越的性能,通过保持每个节点的负载因子相似,根据需要在密集区域添加级别 - 这是桶阵列无法做到的。

谢谢

4

2 回答 2

0

如果您的字符串共享公共前缀,则尝试很好。在这种情况下,前缀只存储一次,并且可以在输出字符串长度中以线性性能进行查询。在存储桶数组中,具有相同前缀的所有字符串最终会在您的键空间中靠得很近,因此您的负载非常倾斜,其中大多数存储桶是空的,有些是巨大的。

t更一般地说,如果特定模式(例如字母和h一起)经常出现,尝试也很好。如果有很多这样的模式,则 trie 的树节点的顺序通常会很小,并且几乎不会浪费存储空间。

于 2013-01-01T19:59:18.083 回答
0

我能想到的尝试的优点之一是插入。桶数组可能需要在某些时候调整大小,这是一项昂贵的操作。所以最坏情况下插入 trie 的时间比插入桶数组要好得多。

另一件事是您需要将字符串映射到要与桶数组一起使用的分数。所以如果你有短键,理论上trie会更高效,因为你不需要做映射。

于 2013-01-01T23:00:26.033 回答