【问题标题】:load factor in separate chaining?单独链接中的负载因子?
【发布时间】:2023-03-30 06:03:01
【问题描述】:

为什么建议在分离链中加载因子为 1?

我看到很多人说这是推荐的,但没有明确解释为什么

在开放寻址中,我知道负载因子应该在 0.5 到 0.7 之间,因为在处理冲突时查找未占用索引应该是一种快速操作。但我不明白为什么在分离链接中负载因子为 1 应该更好。我的意思是,如果我有一个大小为 100 的表,是否还有机会将所有 100 个元素散列到同一个索引并放在同一个列表中?天哪,我真的无法理解为什么单独链接的这个特定负载因子应该是 1。

【问题讨论】:

    标签: hash hashtable hash-function load-factor


    【解决方案1】:

    tl;dr:通过有未占用的插槽通过最小化列表遍历操作的次数来加速访问来节省内存空间。

    如果您将负载系数理解为n_used_slots / n_total_slots

    负载因子为 1 仅描述了使用分离链冲突处理实现良好哈希表的理想情况:没有插槽是空的。

    另一种经典方法 Open Addressing 要求表在添加新项目时始终有可用的空闲槽。为每个项目调整表格大小的成本太高,但我们也受到内存限制,并且不希望周围有太多未使用的插槽。人们必须在速度(很少的表调整大小、快速插入和查找)和内存(很少的空插槽)[编程中经常如此]之间找到平衡。 理想的负载因子就是基于这种平衡的思想,可以根据实际的散列函数、值域等因素进行估计。

    另一方面,使用分离链,我们通常期望从一开始就有(方式)比可用的哈希表槽更多的项目。如果发生冲突,我们需要将项目添加到存储在特定插槽中的链表中。由于在链表中搜索成本很高,我们希望尽量减少列表遍历操作。为此,最好的情况是让 all 插槽充满理想长度相同的列表!填满所有插槽对应于负载因子 1。

    换一种说法:负载因子

    关于大小为 100 的表的示例:是的,有可能所有项目发生碰撞并仅占用一个插槽。在这种情况下,有效负载因子将为 0.01,性能将受到严重影响。

    如果您将负载系数理解为n_items / n_total_slots

    在这种情况下,负载因子可以大于 1。因子 1 表示存在多个槽,因此需要遍历列表。在第一种情况下,您正在浪费空间,而在第二种情况下,列表遍历会导致(小)性能损失,具体取决于列表的大小。

    示例:负载因子为 10 意味着平均每个插槽可容纳 10 个项目。因此,搜索一个项目意味着平均遍历 5 个列表节点。

    负载因子为 1 意味着您不会浪费空间并且具有最快的查找速度,如果您使用了一个不错的散列函数来确保插槽的定期和均匀平衡的使用。

    【讨论】:

    • 负载因子>1 如何在速度方面提高性能?诚然,负载因子>1 可以节省空间,但链表遍历也会影响性能。当负载因子> 1 时,性能如何保持不受影响?这是否意味着重新散列?
    • 我更新了我的答案,将 负载因子 定义为项目数与插槽数。
    • “负载系数 [items / total slots] 为 1 意味着您不会浪费空间......”我不确定这是否正确。如果我有 N 个元素和 N 个桶,并且我使用理想的随机函数来分配元素,我想我应该期望 1/e ≈ 37% 的桶平均是空的。
    猜你喜欢
    • 2019-04-14
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-03-26
    • 2012-10-06
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多