Polish the chapter of graph, hashing, appendix

docs/chapter_hashing/hash_collision.md

@@ -1,79 +1,79 @@
 # 哈希冲突
 
-理想情况下，哈希函数应该为每个输入产生唯一的输出，使得 key 和 value 一一对应。而实际上，往往存在向哈希函数输入不同的 key 而产生相同输出的情况，这种情况被称为「哈希冲突 Hash Collision」。哈希冲突会导致查询结果错误，从而严重影响哈希表的可用性。
+在理想情况下，哈希函数应为每个输入生成唯一的输出，实现 key 和 value 的一一对应。然而实际上，向哈希函数输入不同的 key 却产生相同输出的情况是存在的，这种现象被称为「哈希冲突 Hash Collision」。哈希冲突可能导致查询结果错误，从而严重影响哈希表的可用性。
 
-那么，为什么会出现哈希冲突呢？本质上看，**由于哈希函数的输入空间往往远大于输出空间**，因此不可避免地会出现多个输入产生相同输出的情况，即为哈希冲突。比如，输入空间是全体整数，输出空间是一个固定大小的数组，那么必定会有多个整数映射到同一个数组索引。
+那么，为何会出现哈希冲突呢？从本质上看，由于哈希函数的输入空间通常远大于输出空间，因此多个输入产生相同输出的情况是不可避免的。例如，若输入空间为全体整数，而输出空间为固定大小的数组，则必然有多个整数映射至同一数组索引。
 
-为了缓解哈希冲突，一方面，**我们可以通过哈希表扩容来减小冲突概率**。极端情况下，当输入空间和输出空间大小相等时，哈希表就等价于数组了，每个 key 都对应唯一的数组索引，可谓“大力出奇迹”。
+为了减轻哈希冲突，一方面，**可以通过扩大哈希表容量来降低冲突概率**。极端情况下，当输入空间和输出空间大小相等时，哈希表等同于数组，每个 key 都对应唯一的数组索引，可谓“大力出奇迹”。
 
-另一方面，**考虑通过优化哈希表的表示来缓解哈希冲突**，常见的方法有「链式地址 Separate Chaining」和「开放寻址 Open Addressing」。
+另一方面，**可以考虑优化哈希表的表示以缓解哈希冲突**，常用方法包括「链式地址 Separate Chaining」和「开放寻址 Open Addressing」。
 
 ## 哈希表扩容
 
-哈希函数的最后一步往往是对桶数量 $n$ 取余，以将哈希值映射到桶的索引范围，从而将 key 放入对应的桶中。当哈希表容量越大（即 $n$ 越大）时，多个 key 被分配到同一个桶中的概率就越低，冲突就越少。
+哈希函数的最后一步通常是对桶数量 $n$ 取余，作用是将哈希值映射到桶索引范围，从而将 key 放入对应的桶中。当哈希表容量越大（即 $n$ 越大）时，多个 key 被分配到同一个桶中的概率就越低，冲突就越少。
 
-因此，**在哈希表内的冲突整体比较严重时，编程语言一般通过扩容哈希表来缓解**。与数组扩容类似，哈希表扩容需要将所有键值对从原哈希表移动至新哈希表，**开销很大**。
+因此，**当哈希表内的冲突总体较为严重时，编程语言通常通过扩容哈希表来缓解冲突**。类似于数组扩容，哈希表扩容需将所有键值对从原哈希表迁移至新哈希表，开销较大。
 
-编程语言一般使用「负载因子 Load Factor」来评估哈希冲突的严重程度，**其定义为哈希表中元素数量除以桶数量**，常用作哈希表扩容的触发条件。比如在 Java 中，当负载因子 $> 0.75$ 时，系统会将 HashMap 容量扩充至原先的 $2$ 倍。
+编程语言通常使用「负载因子 Load Factor」来衡量哈希冲突的严重程度，**定义为哈希表中元素数量除以桶数量**，常作为哈希表扩容的触发条件。在 Java 中，当负载因子 $> 0.75$ 时，系统会将 HashMap 容量扩展为原先的 $2$ 倍。
 
 ## 链式地址
 
-在原始哈希表中，每个桶只能存储一个键值对。**链式地址考虑将单个元素转化成一个链表，将键值对作为链表结点，将所有冲突键值对都存储在一个链表中**。
+在原始哈希表中，每个桶仅能存储一个键值对。**链式地址将单个元素转换为链表，将键值对作为链表节点，将所有发生冲突的键值对都存储在同一链表中**。
 
 ![链式地址](hash_collision.assets/hash_collision_chaining.png)
 
-链式地址下，哈希表操作方法为：
+链式地址下，哈希表的操作方法包括：
 
-- **查询元素**：输入 key ，经过哈希函数得到数组索引，即可访问链表头结点，再通过遍历链表并对比 key 来查找键值对。
-- **添加元素**：先通过哈希函数访问链表头结点，再将结点（即键值对）添加到链表即可。
-- **删除元素**：同样先根据哈希函数结果访问链表头部，再遍历链表查找对应结点，删除之即可。
+- **查询元素**：输入 key ，经过哈希函数得到数组索引，即可访问链表头结点，然后遍历链表并对比 key 以查找目标键值对。
+- **添加元素**：先通过哈希函数访问链表头结点，然后将结点（即键值对）添加到链表中。
+- **删除元素**：根据哈希函数的结果访问链表头部，接着遍历链表以查找目标结点，并将其删除。
 
-链式地址虽然解决了哈希冲突问题，但仍存在局限性，包括：
+尽管链式地址法解决了哈希冲突问题，但仍存在一些局限性，包括：
 
-- **占用空间变大**，因为链表或二叉树包含结点指针，相比于数组更加耗费内存空间；
+- **占用空间增大**，由于链表或二叉树包含结点指针，相比数组更加耗费内存空间；
 - **查询效率降低**，因为需要线性遍历链表来查找对应元素；
 
-为了提升操作效率，**可以把「链表」转化为「AVL 树」或「红黑树」**，将查询操作的时间复杂度优化至 $O(\log n)$ 。
+为了提高操作效率，**可以将链表转换为「AVL 树」或「红黑树」**，将查询操作的时间复杂度优化至 $O(\log n)$ 。
 
 ## 开放寻址
 
-「开放寻址」不引入额外数据结构，而是通过“多次探测”来解决哈希冲突。根据探测方法的不同，主要分为 **线性探测、平方探测、多次哈希**。
+「开放寻址」方法不引入额外的数据结构，而是通过“多次探测”来解决哈希冲突，**探测方主要包括线性探测、平方探测、多次哈希**。
 
 ### 线性探测
 
-「线性探测」使用固定步长的线性查找来解决哈希冲突。
+「线性探测」采用固定步长的线性查找来解决哈希冲突。
 
-**插入元素**：如果出现哈希冲突，则从冲突位置向后线性遍历（步长一般取 1 ），直到找到一个空位，则将元素插入到该空位中。
+**插入元素**：若出现哈希冲突，则从冲突位置向后线性遍历（步长通常为 $1$ ），直至找到空位，将元素插入其中。
 
-**查找元素**：若出现哈希冲突，则使用相同步长执行线性查找，会遇到两种情况：
+**查找元素**：在出现哈希冲突时，使用相同步长进行线性查找，可能遇到以下两种情况。
 
 1. 找到对应元素，返回 value 即可；
-2. 若遇到空位，则说明查找键值对不在哈希表中；
+2. 若遇到空位，说明目标键值对不在哈希表中；
 
 ![线性探测](hash_collision.assets/hash_collision_linear_probing.png)
 
 线性探测存在以下缺陷：
 
-- **不能直接删除元素**。删除元素会导致数组内出现一个空位，在查找其他元素时，该空位有可能导致程序认为元素不存在（即上述第 `2.` 种情况）。因此需要借助一个标志位来标记删除元素。
-- **容易产生聚集**。数组内被占用的连续位置越长，这些连续位置发生哈希冲突的可能性越大，从而进一步促进这一位置的“聚堆生长”，最终导致增删查改操作效率的劣化。
+- **不能直接删除元素**。删除元素会在数组内产生一个空位，查找其他元素时，该空位可能导致程序误判元素不存在（即上述第 `2.` 种情况）。因此，需要借助一个标志位来标记已删除元素。
+- **容易产生聚集**。数组内连续被占用位置越长，这些连续位置发生哈希冲突的可能性越大，进一步促使这一位置的“聚堆生长”，最终导致增删查改操作效率降低。
 
 ### 多次哈希
 
-顾名思义，「多次哈希」的思路是使用多个哈希函数 $f_1(x)$ , $f_2(x)$ , $f_3(x)$ , $\cdots$ 进行探测。
+顾名思义，「多次哈希」方法是使用多个哈希函数 $f_1(x)$ , $f_2(x)$ , $f_3(x)$ , $\cdots$ 进行探测。
 
-**插入元素**：若哈希函数 $f_1(x)$ 出现冲突，则尝试 $f_2(x)$ ，以此类推……直到找到空位后插入元素。
+**插入元素**：若哈希函数 $f_1(x)$ 出现冲突，则尝试 $f_2(x)$ ，以此类推，直到找到空位后插入元素。
 
-**查找元素**：以相同的哈希函数顺序查找，存在两种情况：
+**查找元素**：在相同的哈希函数顺序下进行查找，存在以下两种情况：
 
-1. 找到目标元素，则返回之；
-2. 到空位或已尝试所有哈希函数，说明哈希表中无此元素；
+1. 如果找到目标元素，则返回之；
+2. 若遇到空位或已尝试所有哈希函数，则说明哈希表中不存在该元素；
 
-相比于「线性探测」，「多次哈希」方法更不容易产生聚集，代价是多个哈希函数增加了额外计算量。
+与线性探测相比，多次哈希方法不易产生聚集，但多个哈希函数会增加额外的计算量。
 
-!!! note "工业界方案"
+!!! note "哈希表设计方案"
 
-    Java 采用「链式地址」。在 JDK 1.8 之后，HashMap 内数组长度大于 64 时，长度大于 8 的链表会被转化为「红黑树」，以提升查找性能。
+    Java 采用「链式地址」。自 JDK 1.8 以来，当 HashMap 内数组长度大于 64 且链表长度大于 8 时，链表会被转换为「红黑树」以提升查找性能。
 
-    Python 采用「开放寻址」。字典 dict 使用伪随机数进行探测。 
+    Python 采用「开放寻址」。字典 dict 使用伪随机数进行探测。
 
-    Golang 采用「链式地址」。Go 规定每个桶最多存储 8 个键值对，超出容量则连接一个溢出桶；当溢出桶过多时，会执行一次特殊的等量扩容操作，以保证性能。
+    Golang 采用「链式地址」。Go 规定每个桶最多存储 8 个键值对，超出容量则连接一个溢出桶；当溢出桶过多时，会执行一次特殊的等量扩容操作，以确保性能。

docs/chapter_hashing/hash_map.md

@@ -1,21 +1,21 @@
 # 哈希表
 
-哈希表通过建立「键 key」和「值 value」之间的映射，实现高效的元素查找。具体地，输入一个 key ，在哈希表中查询并获取 value ，时间复杂度为 $O(1)$ 。
+哈希表通过建立「键 key」与「值 value」之间的映射，实现高效的元素查询。具体而言，我们向哈希表输入一个 key，则可以在 $O(1)$ 时间内获取对应的 value 。
 
-例如，给定一个包含 $n$ 个学生的数据库，每个学生有“姓名 `name` ”和“学号 `id` ”两项数据，希望实现一个查询功能：**输入一个学号，返回对应的姓名**，则可以使用哈希表实现。
+以一个包含 $n$ 个学生的数据库为例，每个学生都有“姓名 `name`”和“学号 `id`”两项数据。假如我们希望实现查询功能，例如“输入一个学号，返回对应的姓名”，则可以采用哈希表来实现。
 
 ![哈希表的抽象表示](hash_map.assets/hash_map.png)
 
 ## 哈希表效率
 
-除了哈希表之外，还可以使用以下数据结构来实现上述查询功能：
+除哈希表外，还可以使用以下数据结构来实现上述查询功能：
 
 1. **无序数组**：每个元素为  `[学号, 姓名]` ；
 2. **有序数组**：将 `1.` 中的数组按照学号从小到大排序；
 3. **链表**：每个结点的值为 `[学号, 姓名]` ；
 4. **二叉搜索树**：每个结点的值为 `[学号, 姓名]` ，根据学号大小来构建树；
 
-使用上述方法，各项操作的时间复杂度如下表所示（在此不做赘述，详解可见 [二叉搜索树章节](https://www.hello-algo.com/chapter_tree/binary_search_tree/)）。无论是查找元素、还是增删元素，哈希表的时间复杂度都是 $O(1)$ ，全面胜出！
+各项操作的时间复杂度如下表所示（详解可见[二叉搜索树章节](https://www.hello-algo.com/chapter_tree/binary_search_tree/)）。无论是查找元素还是增删元素，哈希表的时间复杂度都是 $O(1)$，全面胜出！
 
 <div class="center-table" markdown>
 
@@ -390,18 +390,18 @@
 
 ## 哈希函数
 
-哈希表的底层实现是数组，并且可能包含链表、二叉树（红黑树）等数据结构，以提升查询性能（下节会讨论）。
+哈希表的底层实现为数组，同时可能包含链表、二叉树（红黑树）等数据结构，以提高查询性能（将在下节讨论）。
 
-首先考虑最简单的情况，**仅用一个「数组」来实现哈希表**。根据习惯，我们将数组中的每个空位称为「桶 Bucket」，用于存储键值对。
+首先考虑最简单的情况，**仅使用一个数组来实现哈希表**。通常，我们将数组中的每个空位称为「桶 Bucket」，用于存储键值对。
 
-我们将键值对 key, value 包装成一个类 `Entry` ，并将所有 `Entry` 都放入数组中，那么每个 `Entry` 在数组中都有唯一的索引。而为了建立 key 和索引之间的映射关系，我们需要使用「哈希函数 Hash Function」。
+我们将键值对 key, value 封装成一个类 `Entry` ，并将所有 `Entry` 放入数组中。这样，数组中的每个 `Entry` 都具有唯一的索引。为了建立 key 和索引之间的映射关系，我们需要使用「哈希函数 Hash Function」。
 
-设哈希表的数组为 `buckets` ，哈希函数为 `f(x)` ，那么查询操作的步骤为：
+设哈希表的数组为 `buckets` ，哈希函数为 `f(x)` ，那么查询操作的步骤如下：
 
 1. 输入 `key` ，通过哈希函数计算出索引 `index` ，即 `index = f(key)` ；
-2. 通过索引在数组中访问到键值对 `entry` ，即 `entry = buckets[index]` ，并在 `entry` 中获取到 `value` 即可；
+2. 通过索引在数组中访问到键值对 `entry` ，即 `entry = buckets[index]` ，然后从 `entry` 中获取对应的 `value` ；
 
-以上述学生数据 `key 学号 -> value 姓名` 为例，我们可以将「哈希函数」设计为
+以学生数据 `key 学号 -> value 姓名` 为例，我们可以设计如下哈希函数：
 
 $$
 f(x) = x \% 100
@@ -491,18 +491,18 @@ $$
 
 ## 哈希冲突
 
-细心的同学可能会发现，**哈希函数 $f(x) = x \% 100$ 会在某些情况下失效**。具体地，当输入的 key 后两位相同时，哈希函数的计算结果也相同，指向同一个 value 。例如，分别查询两个学号 $12836$ 和 $20336$ ，则有
+细心的你可能已经注意到，**在某些情况下，哈希函数 $f(x) = x % 100$ 可能无法正常工作**。具体来说，当输入的 key 后两位相同时，哈希函数的计算结果也会相同，从而指向同一个 value 。例如，查询学号为 $12836$ 和 $20336$ 的两个学生时，我们得到：
 
 $$
 f(12836) = f(20336) = 36
 $$
 
-两个学号指向了同一个姓名，这明显是不对的，我们将这种现象称为「哈希冲突 Hash Collision」。如何避免哈希冲突的问题将被留在下章讨论。
+这两个学号指向了同一个姓名，这显然是错误的。我们把这种情况称为「哈希冲突 Hash Collision」。在后续章节中，我们将讨论如何解决哈希冲突的问题。
 
 ![哈希冲突示例](hash_map.assets/hash_collision.png)
 
-综上所述，一个优秀的「哈希函数」应该具备以下特性：
+综上所述，一个优秀的哈希函数应具备以下特性：
 
-- 尽量少地发生哈希冲突；
-- 时间复杂度 $O(1)$ ，计算尽可能高效；
-- 空间使用率高，即“键值对占用空间 / 哈希表总占用空间”尽可能大；
+- 尽可能减少哈希冲突的发生；
+- 查询效率高且稳定，能够在绝大多数情况下达到 $O(1)$ 时间复杂度；
+- 较高的空间利用率，即使“键值对占用空间 / 哈希表总占用空间”比例最大化；

docs/chapter_hashing/summary.md

@@ -1,11 +1,11 @@
 # 小结
 
-- 向哈希表中输入一个键 key ，查询到值 value 的时间复杂度为 $O(1)$ ，非常高效。
-- 哈希表的常用操作包括查询、添加与删除键值对、遍历键值对等。
-- 哈希函数将 key 映射到桶（数组）索引，从而访问到对应的值 value 。
-- 两个不同的 key 经过哈希函数可能得到相同的桶索引，进而发生哈希冲突，导致查询错误。
-- 缓解哈希冲突的途径有两种：哈希表扩容、优化哈希表的表示方式。
-- 负载因子定义为哈希表中元素数量除以桶槽数量，体现哈希冲突的严重程度，常用作哈希表扩容的触发条件。与数组扩容的原理类似，哈希表扩容操作开销也很大。
-- 链式地址考虑将单个元素转化成一个链表，将所有冲突元素都存储在一个链表中，从而解决哈希冲突。链表过长会导致查询效率变低，可以通过把链表转化为 AVL 树或红黑树来解决。
-- 开放寻址通过多次探测来解决哈希冲突。线性探测使用固定步长，缺点是不能删除元素且容易产生聚集。多次哈希使用多个哈希函数进行探测，相对线性探测不容易产生聚集，代价是多个哈希函数增加了计算量。
-- 在工业界中，Java 的 HashMap 采用链式地址、Python 的 Dict 采用开放寻址。
+- 哈希表能够在 $O(1)$ 时间内将键 key 映射到值 value，效率非常高。
+- 常见的哈希表操作包括查询、添加与删除键值对、遍历键值对等。
+- 哈希函数将 key 映射为数组索引（桶），以便访问对应的值 value 。
+- 两个不同的 key 可能在经过哈希函数后得到相同的索引，导致查询结果出错，这种现象被称为哈希冲突。
+- 缓解哈希冲突的方法主要有扩容哈希表和优化哈希表的表示方法。
+- 负载因子定义为哈希表中元素数量除以桶数量，反映了哈希冲突的严重程度，常用作触发哈希表扩容的条件。与数组扩容类似，哈希表扩容操作也会产生较大的开销。
+- 链式地址通过将单个元素转化为链表，将所有冲突元素存储在同一个链表中，从而解决哈希冲突。然而，过长的链表会降低查询效率，可以通过将链表转换为 AVL 树或红黑树来改善。
+- 开放寻址通过多次探测来解决哈希冲突。线性探测使用固定步长，缺点是不能删除元素且容易产生聚集。多次哈希使用多个哈希函数进行探测，相对线性探测不易产生聚集，但多个哈希函数增加了计算量。
+- 不同编程语言采取了不同的哈希表实现策略。例如，Java 的 HashMap 使用链式地址，而 Python 的 Dict 采用开放寻址。