如何解决哈希表中的渐近运行时间
由于我们知道，如果哈希函数均匀地分配条目，则哈希表的查询时间为O（1）。
什么是渐近运行时间？
（a）在单独链接的哈希表中添加n个具有连续键的条目（插入所有条目的时间，而不是每个条目的插入时间）
（b）搜索不在表中的键。
我的理解是，将键插入哈希表的操作是O（1），因此要插入这样的n个条目将是O（n）。对于b部分，表中不存在的键被认为是最坏的情况，因此搜索的渐近运行时间为O（n），因为它将需要搜索表中的所有n个值。
解决方法
关于a），您是对的-它是O（n），其中n是要插入的新密钥的数目，因为相对于先前存在的密钥数目，每个密钥都是O（1）。
对于b）-您错了-它是O（1）。搜索不在表中的密钥只需要穷举搜索散列了密钥的存储桶，并且该存储桶的预期长度大致由负载系数（即密钥与存储桶的比率）给出。大多数哈希表旨在将负载因子保持在特定范围内，并在添加更多键时调整哈希表的大小。
例如，C ++标准将默认max_load_factor指定为1.0，因此，如果将说第129个元素插入具有128个存储桶的表中，它将调整整个内容的大小，使其可能具有256个存储桶（MS Visual C ++使用2的幂次存储区计数来将哈希值快速按位屏蔽到存储区，GCC使用质数减少冲突。无论如何，当负载系数保持在这样的范围内（例如〜0.5到1.0）时，您很难在存储桶中找到几个以上的元素，而您将搜索实际上不在表中的键。>
除了单独的链接之外，还有另一种将数据存储在哈希表中的方式称为封闭哈希或开放式寻址，其中-如果发生冲突，则可以使用其他存储桶。选择这些存储桶的方法有很多：线性探测意味着您查看连续的存储桶，二次探测意味着您尝试例如哈希存储桶中的+ 1，+ 4，+ 9，+ 16。使用这些方法，当负载因子接近1.0时，或者散列函数质量较差时，您更有可能达到O（N）的最坏情况性能，但是如果您使用的是散列表，则毫无意义不会阻止这种情况，并且具有较低的负载因子或更好的哈希函数-可以将性能保持在O（1）摊销水平。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
