This commit is contained in:
krahets
2025-09-20 20:08:06 +08:00
parent ae2e2535f4
commit 1fca6ca899
9 changed files with 30 additions and 10 deletions

View File

@@ -51,3 +51,9 @@ comments: true
假设取 $n = 8$ ,你可能会发现每条曲线的值与函数对应不上。这是因为每条曲线都包含一个常数项,用于将取值范围压缩到一个视觉舒适的范围内。
在实际中,因为我们通常不知道每个方法的“常数项”复杂度是多少,所以一般无法仅凭复杂度来选择 $n = 8$ 之下的最优解法。但对于 $n = 8^5$ 就很好选了,这时增长趋势已经占主导了。
**Q** 是否存在根据实际使用场景,选择牺牲时间(或空间)来设计算法的情况?
在实际应用中,大部分情况会选择牺牲空间换时间。例如数据库索引,我们通常选择建立 B+ 树或哈希索引,占用大量内存空间,以换取 $O(\log n)$ 甚至 $O(1)$ 的高效查询。
在空间资源宝贵的场景,也会选择牺牲时间换空间。例如在嵌入式开发中,设备内存很宝贵,工程师可能会放弃使用哈希表,选择使用数组顺序查找,以节省内存占用,代价是查找变慢。

View File

@@ -571,7 +571,7 @@ comments: true
输入一个 `key` ,哈希函数的计算过程分为以下两步。
1. 通过某种哈希算法 `hash()` 计算得到哈希值。
2. 将哈希值对桶数量(数组长度)`capacity` 取模,从而获取该 `key` 对应的数组索引 `index` 。
2. 将哈希值对桶数量(数组长度)`capacity` 取模,从而获取该 `key` 对应的桶(数组索引`index` 。
```shell
index = hash(key) % capacity
@@ -610,7 +610,7 @@ index = hash(key) % capacity
index = key % 100
return index
def get(self, key: int) -> str:
def get(self, key: int) -> str | None:
"""查询操作"""
index: int = self.hash_func(key)
pair: Pair = self.buckets[index]
@@ -619,7 +619,7 @@ index = hash(key) % capacity
return pair.val
def put(self, key: int, val: str):
"""添加操作"""
"""添加和更新操作"""
pair = Pair(key, val)
index: int = self.hash_func(key)
self.buckets[index] = pair

View File

@@ -49,3 +49,7 @@ comments: true
**Q**:为什么哈希表扩容能够缓解哈希冲突?
哈希函数的最后一步往往是对数组长度 $n$ 取模(取余),让输出值落在数组索引范围内;在扩容后,数组长度 $n$ 发生变化,而 `key` 对应的索引也可能发生变化。原先落在同一个桶的多个 `key` ,在扩容后可能会被分配到多个桶中,从而实现哈希冲突的缓解。
**Q**:如果为了高效的存取,那么直接使用数组不就好了吗?
当数据的 `key` 是连续的小范围整数时,直接用数组即可,简单高效。但当 `key` 是其他类型(例如字符串)时,就需要借助哈希函数将 `key` 映射为数组索引,再通过桶数组存储元素,这样的结构就是哈希表。

View File

@@ -6,7 +6,7 @@ comments: true
<u>栈stack</u>是一种遵循先入后出逻辑的线性数据结构。
我们可以将栈类比为桌面上的一摞盘子,如果想取出底部的盘子,则需要先将上面的盘子依次移走。我们将盘子替换为各种类型的元素(如整数、字符、对象等),就得到了栈这种数据结构。
我们可以将栈类比为桌面上的一摞盘子,规定每次只能移动一个盘子,那么想取出底部的盘子,则需要先将上面的盘子依次移走。我们将盘子替换为各种类型的元素(如整数、字符、对象等),就得到了栈这种数据结构。
如图 5-1 所示,我们把堆叠元素的顶部称为“栈顶”,底部称为“栈底”。将把元素添加到栈顶的操作叫作“入栈”,删除栈顶元素的操作叫作“出栈”。