From 3f4e32b2b0b9bf1fa92f44543795705c17e9decb Mon Sep 17 00:00:00 2001 From: krahets Date: Sun, 9 Apr 2023 03:09:06 +0800 Subject: [PATCH] Polish the chapter of graph, hashing, appendix --- .../linkedlist_stack.dart | 2 +- .../dart/chapter_tree/binary_search_tree.dart | 4 +- codes/dart/chapter_tree/binary_tree.dart | 2 +- codes/dart/chapter_tree/binary_tree_bfs.dart | 6 +- codes/dart/chapter_tree/binary_tree_dfs.dart | 6 +- codes/rust/chapter_tree/binary_tree.rs | 2 +- docs/chapter_appendix/contribution.md | 28 ++++---- .../space_complexity.md | 2 +- .../summary.md | 4 +- docs/chapter_graph/graph.md | 52 +++++++-------- docs/chapter_graph/graph_operations.md | 24 +++---- docs/chapter_graph/graph_traversal.md | 36 +++++------ docs/chapter_graph/summary.md | 20 +++--- docs/chapter_hashing/hash_collision.md | 64 +++++++++---------- docs/chapter_hashing/hash_map.md | 32 +++++----- docs/chapter_hashing/summary.md | 18 +++--- 16 files changed, 151 insertions(+), 151 deletions(-) diff --git a/codes/dart/chapter_stack_and_queue/linkedlist_stack.dart b/codes/dart/chapter_stack_and_queue/linkedlist_stack.dart index a1dbd46b7..1a88b2b01 100644 --- a/codes/dart/chapter_stack_and_queue/linkedlist_stack.dart +++ b/codes/dart/chapter_stack_and_queue/linkedlist_stack.dart @@ -8,7 +8,7 @@ import '../utils/list_node.dart'; /* 基于链表类实现的栈 */ class LinkedListStack { - ListNode? _stackPeek; // 将头节点作为栈顶 + ListNode? _stackPeek; // 将头结点作为栈顶 int _stkSize = 0; // 栈的长度 LinkedListStack() { diff --git a/codes/dart/chapter_tree/binary_search_tree.dart b/codes/dart/chapter_tree/binary_search_tree.dart index fbebdff3a..8efc4f09e 100644 --- a/codes/dart/chapter_tree/binary_search_tree.dart +++ b/codes/dart/chapter_tree/binary_search_tree.dart @@ -15,7 +15,7 @@ void binarySearchTree(List nums) { root = buildTree(nums, 0, nums.length - 1); // 构建二叉搜索树 } -/* 获取二叉树的根节点 */ +/* 获取二叉树的根结点 */ TreeNode? getRoot() { return root; } @@ -146,7 +146,7 @@ void main() { /* 插入结点 */ node = insert(16); - print("\n插入节点 16 后，二叉树为\n"); + print("\n插入结点 16 后，二叉树为\n"); printTree(getRoot()); /* 删除结点 */ diff --git a/codes/dart/chapter_tree/binary_tree.dart b/codes/dart/chapter_tree/binary_tree.dart index c0dba1c24..2cfc45a8b 100644 --- a/codes/dart/chapter_tree/binary_tree.dart +++ b/codes/dart/chapter_tree/binary_tree.dart @@ -25,7 +25,7 @@ void main() { /* 插入与删除结点 */ TreeNode p = TreeNode(0); - // 在 n1 -> n2 中间插入节点 p + // 在 n1 -> n2 中间插入结点 p n1.left = p; p.left = n2; print("\n插入结点 P 后\n"); diff --git a/codes/dart/chapter_tree/binary_tree_bfs.dart b/codes/dart/chapter_tree/binary_tree_bfs.dart index 49462f18c..2d097dc3f 100644 --- a/codes/dart/chapter_tree/binary_tree_bfs.dart +++ b/codes/dart/chapter_tree/binary_tree_bfs.dart @@ -10,7 +10,7 @@ import '../utils/tree_node.dart'; /* 层序遍历 */ List levelOrder(TreeNode? root) { - // 初始化队列，加入根节点 + // 初始化队列，加入根结点 Queue queue = Queue(); queue.add(root); // 初始化一个列表，用于保存遍历序列 @@ -18,8 +18,8 @@ List levelOrder(TreeNode? root) { while (queue.isNotEmpty) { TreeNode? node = queue.removeFirst(); // 队列出队 res.add(node!.val); // 保存结点值 - if (node.left != null) queue.add(node.left); // 左子节点入队 - if (node.right != null) queue.add(node.right); // 右子节点入队 + if (node.left != null) queue.add(node.left); // 左子结点入队 + if (node.right != null) queue.add(node.right); // 右子结点入队 } return res; } diff --git a/codes/dart/chapter_tree/binary_tree_dfs.dart b/codes/dart/chapter_tree/binary_tree_dfs.dart index ffd6fa141..77c90fb86 100644 --- a/codes/dart/chapter_tree/binary_tree_dfs.dart +++ b/codes/dart/chapter_tree/binary_tree_dfs.dart @@ -13,7 +13,7 @@ List list = []; /* 前序遍历 */ void preOrder(TreeNode? node) { if (node == null) return; - // 访问优先级：根节点 -> 左子树 -> 右子树 + // 访问优先级：根结点 -> 左子树 -> 右子树 list.add(node.val); preOrder(node.left); preOrder(node.right); @@ -22,7 +22,7 @@ void preOrder(TreeNode? node) { /* 中序遍历 */ void inOrder(TreeNode? node) { if (node == null) return; - // 访问优先级：左子树 -> 根节点 -> 右子树 + // 访问优先级：左子树 -> 根结点 -> 右子树 inOrder(node.left); list.add(node.val); inOrder(node.right); @@ -31,7 +31,7 @@ void inOrder(TreeNode? node) { /* 后序遍历 */ void postOrder(TreeNode? node) { if (node == null) return; - // 访问优先级：左子树 -> 右子树 -> 根节点 + // 访问优先级：左子树 -> 右子树 -> 根结点 postOrder(node.left); postOrder(node.right); list.add(node.val); diff --git a/codes/rust/chapter_tree/binary_tree.rs b/codes/rust/chapter_tree/binary_tree.rs index 737981f89..232ac93f6 100644 --- a/codes/rust/chapter_tree/binary_tree.rs +++ b/codes/rust/chapter_tree/binary_tree.rs @@ -24,7 +24,7 @@ fn main() { println!("\n初始化二叉树\n"); print_util::print_tree(&n1); - // 插入节点与删除节点 + // 插入结点与删除结点 let p = TreeNode::new(0); // 在 n1 -> n2 中间插入结点 P p.borrow_mut().left = Some(Rc::clone(&n2)); diff --git a/docs/chapter_appendix/contribution.md b/docs/chapter_appendix/contribution.md index 788fbe272..2f1a64d49 100644 --- a/docs/chapter_appendix/contribution.md +++ b/docs/chapter_appendix/contribution.md @@ -2,35 +2,35 @@ !!! success "开源的魅力" - 纸质书籍的两次印刷的间隔时间往往需要数年，内容更新非常不方便。
但在本开源 HTML 书中，内容更迭的时间被缩短至数日甚至几个小时。 + 纸质书籍的两次印刷的间隔时间往往需要数年，内容更新非常不方便。
但在本开源书中，内容更迭的时间被缩短至数日甚至几个小时。 -由于作者水平有限，书中内容难免疏漏谬误，请您谅解。如果发现笔误、无效链接、内容缺失、文字歧义、解释不清晰、行文结构不合理等问题，请您帮忙修正，以帮助其他读者获取更优质的学习内容。所有[撰稿人](https://github.com/krahets/hello-algo/graphs/contributors)将被展示在仓库与网站主页，以感谢他们对开源社区的无私奉献！ +由于作者能力有限，书中难免存在一些遗漏和错误，请您谅解。如果您发现了笔误、失效链接、内容缺失、文字歧义、解释不清晰或行文结构不合理等问题，请协助我们进行修正，以帮助其他读者获得更优质的学习资源。所有[撰稿人](https://github.com/krahets/hello-algo/graphs/contributors)将在仓库和网站主页上展示，以感谢他们对开源社区的无私奉献！ ## 内容微调 -每个页面的右上角都有一个「编辑」图标，你可以按照以下步骤修改文字或代码： +在每个页面的右上角有一个「编辑」图标，您可以按照以下步骤修改文本或代码： -1. 点击编辑按钮，如果遇到提示“需要 Fork 此仓库”，请通过； -2. 修改 Markdown 源文件内容，并检查内容正确性，尽量保持排版格式统一； -3. 在页面底部填写更改说明，然后单击“Propose file change”按钮；页面跳转后，点击“Create pull request”按钮发起拉取请求即可。 +1. 点击编辑按钮，如果遇到“需要 Fork 此仓库”的提示，请同意该操作； +2. 修改 Markdown 源文件内容，并确保内容正确，同时尽量保持排版格式的统一； +3. 在页面底部填写修改说明，然后点击“Propose file change”按钮；页面跳转后，点击“Create pull request”按钮即可发起拉取请求。 ![页面编辑按键](contribution.assets/edit_markdown.png) -图片无法直接修改，需要通过新建 [Issue](https://github.com/krahets/hello-algo/issues) 或评论留言来描述图片问题，我会第一时间重新画图并替换图片。 +由于图片无法直接修改，因此需要通过新建 [Issue](https://github.com/krahets/hello-algo/issues) 或评论留言来描述图片问题，我们会尽快重新绘制并替换图片。 ## 内容创作 -如果您想要参与本开源项目，包括翻译代码至其他编程语言、拓展文章内容等，那么需要实施 Pull Request 工作流程： +如果您有兴趣参与此开源项目，包括将代码翻译成其他编程语言、扩展文章内容等，那么需要实施 Pull Request 工作流程： -1. 登录 GitHub ，并 Fork [本仓库](https://github.com/krahets/hello-algo) 至个人账号； -2. 进入 Fork 仓库网页，使用 `git clone` 克隆该仓库至本地； -3. 在本地进行内容创作，并通过运行测试来验证代码正确性； -4. 将本地更改 Commit ，并 Push 至远程仓库； -5. 刷新仓库网页，点击“Create pull request”按钮发起拉取请求即可； +1. 登录 GitHub ，将[本仓库](https://github.com/krahets/hello-algo) Fork 到个人账号下； +2. 进入您的 Fork 仓库网页，使用 git clone 命令将仓库克隆至本地； +3. 在本地进行内容创作，并通过运行测试以验证代码的正确性； +4. 将本地所做更改 Commit ，然后 Push 至远程仓库； +5. 刷新仓库网页，点击“Create pull request”按钮即可发起拉取请求； ## Docker 部署 -你可以使用 Docker 来部署本项目。稍等片刻，即可使用浏览器打开 `http://localhost:8000` 访问本项目。 +我们可以通过 Docker 来部署本项目。执行以下脚本，稍等片刻后，即可使用浏览器打开 `http://localhost:8000` 来访问本项目。 ```shell git clone https://github.com/krahets/hello-algo.git diff --git a/docs/chapter_computational_complexity/space_complexity.md b/docs/chapter_computational_complexity/space_complexity.md index 0a7f4db23..ee6d2ceae 100755 --- a/docs/chapter_computational_complexity/space_complexity.md +++ b/docs/chapter_computational_complexity/space_complexity.md @@ -890,7 +890,7 @@ $$ ### 指数阶 $O(2^n)$ -指数阶常见于二叉树。高度为 $n$ 的「满二叉树」的节点数量为 $2^n - 1$ ，占用 $O(2^n)$ 空间。 +指数阶常见于二叉树。高度为 $n$ 的「满二叉树」的结点数量为 $2^n - 1$ ，占用 $O(2^n)$ 空间。 === "Java" diff --git a/docs/chapter_computational_complexity/summary.md b/docs/chapter_computational_complexity/summary.md index 9f2e84174..973fac6cd 100644 --- a/docs/chapter_computational_complexity/summary.md +++ b/docs/chapter_computational_complexity/summary.md @@ -9,8 +9,8 @@ ### 时间复杂度 - 时间复杂度用于衡量算法运行时间随数据量增长的趋势，可以有效评估算法效率，但在某些情况下可能失效，如在输入数据量较小或时间复杂度相同时，无法精确对比算法效率的优劣。 -- 最差时间复杂度使用大 $O$ 符号表示，即函数渐进上界，反映当 $n$ 趋向正无穷时，$T(n)$ 的增长级别。 -- 推算时间复杂度分为两步，首先统计计算操作数量，然后判断渐进上界。 +- 最差时间复杂度使用大 $O$ 符号表示，即函数渐近上界，反映当 $n$ 趋向正无穷时，$T(n)$ 的增长级别。 +- 推算时间复杂度分为两步，首先统计计算操作数量，然后判断渐近上界。 - 常见时间复杂度从小到大排列有 $O(1)$ , $O(\log n)$ , $O(n)$ , $O(n \log n)$ , $O(n^2)$ , $O(2^n)$ , $O(n!)$ 等。 - 某些算法的时间复杂度非固定，而是与输入数据的分布有关。时间复杂度分为最差、最佳、平均时间复杂度，最佳时间复杂度几乎不用，因为输入数据一般需要满足严格条件才能达到最佳情况。 - 平均时间复杂度反映算法在随机数据输入下的运行效率，最接近实际应用中的算法性能。计算平均时间复杂度需要统计输入数据分布以及综合后的数学期望。 diff --git a/docs/chapter_graph/graph.md b/docs/chapter_graph/graph.md index e14ad918c..1ba32b93b 100644 --- a/docs/chapter_graph/graph.md +++ b/docs/chapter_graph/graph.md @@ -1,6 +1,6 @@ # 图 -「图 Graph」是一种非线性数据结构，由「顶点 Vertex」和「边 Edge」组成。我们可将图 $G$ 抽象地表示为一组顶点 $V$ 和一组边 $E$ 的集合。例如，以下表示一个包含 5 个顶点和 7 条边的图 +「图 Graph」是一种非线性数据结构，由「顶点 Vertex」和「边 Edge」组成。我们可以将图 $G$ 抽象地表示为一组顶点 $V$ 和一组边 $E$ 的集合。以下示例展示了一个包含 5 个顶点和 7 条边的图。 $$ \begin{aligned} @@ -12,53 +12,53 @@ $$ ![链表、树、图之间的关系](graph.assets/linkedlist_tree_graph.png) -那么，图与其他数据结构的关系是什么？如果我们把「顶点」看作结点，把「边」看作连接各个结点的指针，则可将「图」看成一种从「链表」拓展而来的数据结构。**相比线性关系（链表）和分治关系（树），网络关系（图）的自由度更高，也从而更为复杂**。 +那么，图与其他数据结构的关系是什么？如果我们把「顶点」看作结点，把「边」看作连接各个结点的指针，则可将「图」看作是一种从「链表」拓展而来的数据结构。**相较于线性关系（链表）和分治关系（树），网络关系（图）的自由度更高，从而更为复杂**。 ## 图常见类型 -根据边是否有方向，分为「无向图 Undirected Graph」和「有向图 Directed Graph」。 +根据边是否具有方向，可分为「无向图 Undirected Graph」和「有向图 Directed Graph」。 -- 在无向图中，边表示两顶点之间“双向”的连接关系，例如微信或 QQ 中的“好友关系”； -- 在有向图中，边是有方向的，即 $A \rightarrow B$ 和 $A \leftarrow B$ 两个方向的边是相互独立的，例如微博或抖音上的“关注”与“被关注”关系； +- 在无向图中，边表示两顶点之间的“双向”连接关系，例如微信或 QQ 中的“好友关系”； +- 在有向图中，边具有方向性，即 $A \rightarrow B$ 和 $A \leftarrow B$ 两个方向的边是相互独立的，例如微博或抖音上的“关注”与“被关注”关系； ![有向图与无向图](graph.assets/directed_graph.png) -根据所有顶点是否连通，分为「连通图 Connected Graph」和「非连通图 Disconnected Graph」。 +根据所有顶点是否连通，可分为「连通图 Connected Graph」和「非连通图 Disconnected Graph」。 - 对于连通图，从某个顶点出发，可以到达其余任意顶点； - 对于非连通图，从某个顶点出发，至少有一个顶点无法到达； ![连通图与非连通图](graph.assets/connected_graph.png) -我们可以给边添加“权重”变量，得到「有权图 Weighted Graph」。例如，在王者荣耀等游戏中，系统会根据共同游戏时间来计算玩家之间的“亲密度”，这种亲密度网络就可以使用有权图来表示。 +我们还可以为边添加“权重”变量，从而得到「有权图 Weighted Graph」。例如，在王者荣耀等手游中，系统会根据共同游戏时间来计算玩家之间的“亲密度”，这种亲密度网络就可以用有权图来表示。 ![有权图与无权图](graph.assets/weighted_graph.png) ## 图常用术语 -- 「邻接 Adjacency」：当两顶点之间有边相连时，称此两顶点“邻接”。例如，上图中顶点 1 的邻接顶点为顶点 2, 3, 5 。 -- 「路径 Path」：从顶点 A 到顶点 B 走过的边构成的序列，被称为从 A 到 B 的“路径”。例如，上图中边序列 1-5-2-4 是顶点 1 到顶点 4 的一个路径。 -- 「度 Degree」表示一个顶点具有多少条边。对于有向图，「入度 In-Degree」表示有多少条边指向该顶点，「出度 Out-Degree」表示有多少条边从该顶点指出。 +- 「邻接 Adjacency」：当两顶点之间存在边相连时，称这两顶点“邻接”。在上图中，顶点 1 的邻接顶点为顶点 2、3、5。 +- 「路径 Path」：从顶点 A 到顶点 B 经过的边构成的序列被称为从 A 到 B 的“路径”。在上图中，边序列 1-5-2-4 是顶点 1 到顶点 4 的一条路径。 +- 「度 Degree」表示一个顶点拥有的边数。对于有向图，「入度 In-Degree」表示有多少条边指向该顶点，「出度 Out-Degree」表示有多少条边从该顶点指出。 ## 图的表示 -图的常用表示方法有「邻接矩阵」和「邻接表」。以下使用「无向图」来举例。 +图的常用表示方法包括「邻接矩阵」和「邻接表」。以下使用无向图进行举例。 ### 邻接矩阵 -设图的顶点数量为 $n$ ，「邻接矩阵 Adjacency Matrix」使用一个 $n \times n$ 大小的矩阵来表示图，每一行（列）代表一个顶点，矩阵元素代表边，使用 $1$ 或 $0$ 来表示两个顶点之间有边或无边。 +设图的顶点数量为 $n$ ，「邻接矩阵 Adjacency Matrix」使用一个 $n \times n$ 大小的矩阵来表示图，每一行（列）代表一个顶点，矩阵元素代表边，用 $1$ 或 $0$ 表示两个顶点之间是否存在边。 -如下图所示，记邻接矩阵为 $M$ 、顶点列表为 $V$ ，则矩阵元素 $M[i][j] = 1$ 代表着顶点 $V[i]$ 到顶点 $V[j]$ 之间有边，相反地 $M[i][j] = 0$ 代表两顶点之间无边。 +如下图所示，设邻接矩阵为 $M$ 、顶点列表为 $V$ ，那么矩阵元素 $M[i][j] = 1$ 表示顶点 $V[i]$ 到顶点 $V[j]$ 之间存在边，反之 $M[i][j] = 0$ 表示两顶点之间无边。 ![图的邻接矩阵表示](graph.assets/adjacency_matrix.png) -邻接矩阵具有以下性质： +邻接矩阵具有以下特性： -- 顶点不能与自身相连，因而邻接矩阵主对角线元素没有意义。 -- 「无向图」两个方向的边等价，此时邻接矩阵关于主对角线对称。 -- 将邻接矩阵的元素从 $1$ , $0$ 替换为权重，则能够表示「有权图」。 +- 顶点不能与自身相连，因此邻接矩阵主对角线元素没有意义。 +- 对于无向图，两个方向的边等价，此时邻接矩阵关于主对角线对称。 +- 将邻接矩阵的元素从 $1$ , $0$ 替换为权重，则可表示有权图。 -使用邻接矩阵表示图时，我们可以直接通过访问矩阵元素来获取边，因此增删查操作的效率很高，时间复杂度均为 $O(1)$ 。然而，矩阵的空间复杂度为 $O(n^2)$ ，内存占用较大。 +使用邻接矩阵表示图时，我们可以直接访问矩阵元素以获取边，因此增删查操作的效率很高，时间复杂度均为 $O(1)$ 。然而，矩阵的空间复杂度为 $O(n^2)$ ，内存占用较多。 ### 邻接表 @@ -66,20 +66,20 @@ $$ ![图的邻接表表示](graph.assets/adjacency_list.png) -邻接表仅存储存在的边，而边的总数往往远小于 $n^2$ ，因此更加节省空间。但是，因为在邻接表中需要通过遍历链表来查找边，所以其时间效率不如邻接矩阵。 +邻接表仅存储实际存在的边，而边的总数通常远小于 $n^2$ ，因此它更加节省空间。然而，在邻接表中需要通过遍历链表来查找边，因此其时间效率不如邻接矩阵。 -观察上图发现，**邻接表结构与哈希表「链地址法」非常相似，因此我们也可以用类似方法来优化效率**。比如，当链表较长时，可以把链表转化为 AVL 树或红黑树，从而将时间效率从 $O(n)$ 优化至 $O(\log n)$ ，还可以通过中序遍历获取有序序列；还可以将链表转化为哈希表，将时间复杂度降低至 $O(1)$ 。 +观察上图可发现，**邻接表结构与哈希表中的「链地址法」非常相似，因此我们也可以采用类似方法来优化效率**。例如，当链表较长时，可以将链表转化为 AVL 树或红黑树，从而将时间效率从 $O(n)$ 优化至 $O(\log n)$ ，还可以通过中序遍历获取有序序列；此外，还可以将链表转换为哈希表，将时间复杂度降低至 $O(1)$ 。 ## 图常见应用 -现实中的许多系统都可以使用图来建模，对应的待求解问题也可以被约化为图计算问题。 +实际应用中，许多系统都可以用图来建模，相应的待求解问题也可以约化为图计算问题。
-| | 顶点 | 边 | 图计算问题 | -| -------- | ---- | -------------------- | ------------ | -| 社交网络 | 用户 | 好友关系 | 潜在好友推荐 | -| 地铁线路 | 站点 | 站点间的连通性 | 最短路线推荐 | -| 太阳系 | 星体 | 星体间的万有引力作用 | 行星轨道计算 | +| | 顶点 | 边 | 图计算问题 | +| ------ | ---- | --------------- | ------------ | +| 社交网络 | 用户 | 好友关系 | 潜在好友推荐 | +| 地铁线路 | 站点 | 站点间的连通性 | 最短路线推荐 | +| 太阳系 | 星体 | 星体间的万有引力作用 | 行星轨道计算 |
diff --git a/docs/chapter_graph/graph_operations.md b/docs/chapter_graph/graph_operations.md index 2fa70c004..fe4a77be7 100644 --- a/docs/chapter_graph/graph_operations.md +++ b/docs/chapter_graph/graph_operations.md @@ -1,12 +1,12 @@ # 图基础操作 -图的基础操作分为对「边」的操作和对「顶点」的操作，在「邻接矩阵」和「邻接表」这两种表示下的实现方式不同。 +图的基础操作可分为对「边」的操作和对「顶点」的操作。在「邻接矩阵」和「邻接表」两种表示方法下，实现方式有所不同。 ## 基于邻接矩阵的实现 -设图的顶点总数为 $n$ ，则有： +给定一个顶点数量为 $n$ 的无向图，则有： -- **添加或删除边**：直接在邻接矩阵中修改指定边的对应元素即可，使用 $O(1)$ 时间。而由于是无向图，因此需要同时更新两个方向的边。 +- **添加或删除边**：直接在邻接矩阵中修改指定的边即可，使用 $O(1)$ 时间。而由于是无向图，因此需要同时更新两个方向的边。 - **添加顶点**：在邻接矩阵的尾部添加一行一列，并全部填 $0$ 即可，使用 $O(n)$ 时间。 - **删除顶点**：在邻接矩阵中删除一行一列。当删除首行首列时达到最差情况，需要将 $(n-1)^2$ 个元素“向左上移动”，从而使用 $O(n^2)$ 时间。 - **初始化**：传入 $n$ 个顶点，初始化长度为 $n$ 的顶点列表 `vertices` ，使用 $O(n)$ 时间；初始化 $n \times n$ 大小的邻接矩阵 `adjMat` ，使用 $O(n^2)$ 时间。 @@ -90,13 +90,13 @@ ## 基于邻接表的实现 -设图的顶点总数为 $n$ 、边总数为 $m$ ，则有： +设无向图的顶点总数为 $n$ 、边总数为 $m$ ，则有： -- **添加边**：在顶点对应链表的尾部添加边即可，使用 $O(1)$ 时间。因为是无向图，所以需要同时添加两个方向的边。 -- **删除边**：在顶点对应链表中查询与删除指定边，使用 $O(m)$ 时间。与添加边一样，需要同时删除两个方向的边。 -- **添加顶点**：在邻接表中添加一个链表即可，并以新增顶点为链表头结点，使用 $O(1)$ 时间。 -- **删除顶点**：需要遍历整个邻接表，删除包含指定顶点的所有边，使用 $O(n + m)$ 时间。 -- **初始化**：需要在邻接表中建立 $n$ 个结点和 $2m$ 条边，使用 $O(n + m)$ 时间。 +- **添加边**：在顶点对应链表的末尾添加边即可，使用 $O(1)$ 时间。因为是无向图，所以需要同时添加两个方向的边。 +- **删除边**：在顶点对应链表中查找并删除指定边，使用 $O(m)$ 时间。在无向图中，需要同时删除两个方向的边。 +- **添加顶点**：在邻接表中添加一个链表，并将新增顶点作为链表头结点，使用 $O(1)$ 时间。 +- **删除顶点**：需遍历整个邻接表，删除包含指定顶点的所有边，使用 $O(1)$ 时间。 +- **初始化**：在邻接表中创建 $n$ 个顶点和 $2m$ 条边，使用 $O(n + m)$ 时间。 === "初始化邻接表" ![邻接表的初始化、增删边、增删顶点](graph_operations.assets/adjacency_list_initialization.png) @@ -113,10 +113,10 @@ === "删除顶点" ![adjacency_list_remove_vertex](graph_operations.assets/adjacency_list_remove_vertex.png) -基于邻接表实现图的代码如下所示。细心的同学可能注意到，**我们在邻接表中使用 `Vertex` 结点类来表示顶点**，这样做的原因是： +以下是基于邻接表实现图的代码示例。细心的同学可能注意到，**我们在邻接表中使用 `Vertex` 结点类来表示顶点**，这样做的原因有： - 如果我们选择通过顶点值来区分不同顶点，那么值重复的顶点将无法被区分。 -- 如果类似邻接矩阵那样，使用顶点列表索引来区分不同顶点。那么，假设我们想要删除索引为 $i$ 的顶点，则需要遍历整个邻接表，将其中 $> i$ 的索引全部执行 $-1$ ，这样操作效率太低。 +- 如果类似邻接矩阵那样，使用顶点列表索引来区分不同顶点。那么，假设我们想要删除索引为 $i$ 的顶点，则需要遍历整个邻接表，将其中 $> i$ 的索引全部减 $1$，这样操作效率较低。 - 因此我们考虑引入顶点类 `Vertex` ，使得每个顶点都是唯一的对象，此时删除顶点时就无需改动其余顶点了。 === "Java" @@ -196,4 +196,4 @@ -观察上表，貌似邻接表（哈希表）的时间与空间效率最优。但实际上，在邻接矩阵中操作边的效率更高，只需要一次数组访问或赋值操作即可。总结以上，**邻接矩阵体现“以空间换时间”，邻接表体现“以时间换空间”**。 +观察上表，似乎邻接表（哈希表）的时间与空间效率最优。但实际上，在邻接矩阵中操作边的效率更高，只需要一次数组访问或赋值操作即可。综合来看，邻接矩阵体现了“以空间换时间”的原则，而邻接表体现了“以时间换空间”的原则。 diff --git a/docs/chapter_graph/graph_traversal.md b/docs/chapter_graph/graph_traversal.md index b9492a34c..72667f5fb 100644 --- a/docs/chapter_graph/graph_traversal.md +++ b/docs/chapter_graph/graph_traversal.md @@ -2,25 +2,25 @@ !!! note "图与树的关系" - 树代表的是“一对多”的关系，而图则自由度更高，可以代表任意“多对多”关系。本质上，**可以把树看作是图的一类特例**。那么显然，树遍历操作也是图遍历操作的一个特例，两者的方法是非常类似的，建议你在学习本章节的过程中将两者融会贯通。 + 树代表的是“一对多”的关系，而图则具有更高的自由度，可以表示任意的“多对多”关系。因此，我们可以把树看作是图的一种特例。显然，**树的遍历操作也是图的遍历操作的一种特例**，建议你在学习本章节时融会贯通两者的概念与实现方法。 -「图」与「树」都是非线性数据结构，都需要使用「搜索算法」来实现遍历操作。 +「图」和「树」都是非线性数据结构，都需要使用「搜索算法」来实现遍历操作。 -类似地，图的遍历方式也分为两种，即「广度优先遍历 Breadth-First Traversal」和「深度优先遍历 Depth-First Travsersal」，也称「广度优先搜索 Breadth-First Search」和「深度优先搜索 Depth-First Search」，简称为 BFS 和 DFS 。 +与树类似，图的遍历方式也可分为两种，即「广度优先遍历 Breadth-First Traversal」和「深度优先遍历 Depth-First Traversal」，也称为「广度优先搜索 Breadth-First Search」和「深度优先搜索 Depth-First Search」，简称 BFS 和 DFS。 ## 广度优先遍历 -**广度优先遍历优是一种由近及远的遍历方式，从距离最近的顶点开始访问，并一层层向外扩张**。具体地，从某个顶点出发，先遍历该顶点的所有邻接顶点，随后遍历下个顶点的所有邻接顶点，以此类推…… +**广度优先遍历是一种由近及远的遍历方式，从距离最近的顶点开始访问，并一层层向外扩张**。具体来说，从某个顶点出发，先遍历该顶点的所有邻接顶点，然后遍历下一个顶点的所有邻接顶点，以此类推，直至所有顶点访问完毕。 ![图的广度优先遍历](graph_traversal.assets/graph_bfs.png) ### 算法实现 -BFS 常借助「队列」来实现。队列具有“先入先出”的性质，这与 BFS “由近及远”的思想是异曲同工的。 +BFS 通常借助「队列」来实现。队列具有“先入先出”的性质，这与 BFS 的“由近及远”的思想异曲同工。 1. 将遍历起始顶点 `startVet` 加入队列，并开启循环； -2. 在循环的每轮迭代中，弹出队首顶点弹出并记录访问，并将该顶点的所有邻接顶点加入到队列尾部； -3. 循环 `2.` ，直到所有顶点访问完成后结束； +2. 在循环的每轮迭代中，弹出队首顶点并记录访问，然后将该顶点的所有邻接顶点加入到队列尾部； +3. 循环步骤 `2.` ，直到所有顶点被访问完成后结束； 为了防止重复遍历顶点，我们需要借助一个哈希表 `visited` 来记录哪些结点已被访问。 @@ -121,23 +121,23 @@ BFS 常借助「队列」来实现。队列具有“先入先出”的性质， !!! question "广度优先遍历的序列是否唯一？" - 不唯一。广度优先遍历只要求“由近及远”，**而多个相同距离的顶点的遍历顺序允许被任意打乱**。以上图为例，顶点 $1$ , $3$ 的访问顺序可以交换、顶点 $2$ , $4$ , $6$ 的访问顺序也可以任意交换、以此类推…… + 不唯一。广度优先遍历只要求按“由近及远”的顺序遍历，**而多个相同距离的顶点的遍历顺序是允许被任意打乱的**。以上图为例，顶点 $1$ , $3$ 的访问顺序可以交换、顶点 $2$ , $4$ , $6$ 的访问顺序也可以任意交换。 ### 复杂度分析 -**时间复杂度：** 所有顶点都会入队、出队一次，使用 $O(|V|)$ 时间；在遍历邻接顶点的过程中，由于是无向图，因此所有边都会被访问 $2$ 次，使用 $O(2|E|)$ 时间；总体使用 $O(|V| + |E|)$ 时间。 +**时间复杂度：** 所有顶点都会入队并出队一次，使用 $O(|V|)$ 时间；在遍历邻接顶点的过程中，由于是无向图，因此所有边都会被访问 $2$ 次，使用 $O(2|E|)$ 时间；总体使用 $O(|V| + |E|)$ 时间。 **空间复杂度：** 列表 `res` ，哈希表 `visited` ，队列 `que` 中的顶点数量最多为 $|V|$ ，使用 $O(|V|)$ 空间。 ## 深度优先遍历 -**深度优先遍历是一种优先走到底、无路可走再回头的遍历方式**。具体地，从某个顶点出发，不断地访问当前结点的某个邻接顶点，直到走到尽头时回溯，再继续走到底 + 回溯，以此类推……直至所有顶点遍历完成时结束。 +**深度优先遍历是一种优先走到底、无路可走再回头的遍历方式**。具体地，从某个顶点出发，访问当前顶点的某个邻接顶点，直到走到尽头时返回，再继续走到尽头并返回，以此类推，直至所有顶点遍历完成。 ![图的深度优先遍历](graph_traversal.assets/graph_dfs.png) ### 算法实现 -这种“走到头 + 回溯”的算法形式一般基于递归来实现。与 BFS 类似，在 DFS 中我们也需要借助一个哈希表 `visited` 来记录已被访问的顶点，以避免重复访问顶点。 +这种“走到尽头 + 回溯”的算法形式通常基于递归来实现。与 BFS 类似，在 DFS 中我们也需要借助一个哈希表 `visited` 来记录已被访问的顶点，以避免重复访问顶点。 === "Java" @@ -219,12 +219,12 @@ BFS 常借助「队列」来实现。队列具有“先入先出”的性质， [class]{}-[func]{graphDFS} ``` -深度优先遍历的算法流程如下图所示，其中 +深度优先遍历的算法流程如下图所示，其中： -- **直虚线代表向下递推**，代表开启了一个新的递归方法来访问新顶点； -- **曲虚线代表向上回溯**，代表此递归方法已经返回，回溯到了开启此递归方法的位置； +- **直虚线代表向下递推**，表示开启了一个新的递归方法来访问新顶点； +- **曲虚线代表向上回溯**，表示此递归方法已经返回，回溯到了开启此递归方法的位置； -为了加深理解，请你将图示与代码结合起来，在脑中（或者用笔画下来）模拟整个 DFS 过程，包括每个递归方法何时开启、何时返回。 +为了加深理解，建议将图示与代码结合起来，在脑中（或者用笔画下来）模拟整个 DFS 过程，包括每个递归方法何时开启、何时返回。 === "<1>" ![图的深度优先遍历步骤](graph_traversal.assets/graph_dfs_step1.png) @@ -261,12 +261,12 @@ BFS 常借助「队列」来实现。队列具有“先入先出”的性质， !!! question "深度优先遍历的序列是否唯一？" - 与广度优先遍历类似，深度优先遍历序列的顺序也不是唯一的。给定某顶点，先往哪个方向探索都行，都是深度优先遍历。 + 与广度优先遍历类似，深度优先遍历序列的顺序也不是唯一的。给定某顶点，先往哪个方向探索都可以，即邻接顶点的顺序可以任意打乱，都是深度优先遍历。 - 以树的遍历为例，“根 $\rightarrow$ 左 $\rightarrow$ 右”、“左 $\rightarrow$ 根 $\rightarrow$ 右”、“左 $\rightarrow$ 右 $\rightarrow$ 根”分别对应前序、中序、后序遍历，体现三种不同的遍历优先级，而三者都属于深度优先遍历。 + 以树的遍历为例，“根 $\rightarrow$ 左 $\rightarrow$ 右”、“左 $\rightarrow$ 根 $\rightarrow$ 右”、“左 $\rightarrow$ 右 $\rightarrow$ 根”分别对应前序、中序、后序遍历，它们展示了三种不同的遍历优先级，然而这三者都属于深度优先遍历。 ### 复杂度分析 -**时间复杂度：** 所有顶点都被访问一次；所有边都被访问了 $2$ 次，使用 $O(2|E|)$ 时间；总体使用 $O(|V| + |E|)$ 时间。 +**时间复杂度：** 所有顶点都会被访问 $1$ 次，使用 $O(|V|)$ 时间；所有边都会被访问 $2$ 次，使用 $O(2|E|)$ 时间；总体使用 $O(|V| + |E|)$ 时间。 **空间复杂度：** 列表 `res` ，哈希表 `visited` 顶点数量最多为 $|V|$ ，递归深度最大为 $|V|$ ，因此使用 $O(|V|)$ 空间。 diff --git a/docs/chapter_graph/summary.md b/docs/chapter_graph/summary.md index a715f38f1..04d06e895 100644 --- a/docs/chapter_graph/summary.md +++ b/docs/chapter_graph/summary.md @@ -1,13 +1,13 @@ # 小结 -- 图由顶点和边组成，可以表示为一组顶点和一组边构成的集合。 -- 相比线性关系（链表）和分治关系（树），网络关系（图）的自由度更高，也从而更为复杂。 -- 有向图的边存在方向，连通图中的任意顶点都可达，有权图的每条边都包含权重变量。 -- 邻接矩阵使用方阵来表示图，每一行（列）代表一个顶点，矩阵元素代表边，使用 $1$ 或 $0$ 来表示两个顶点之间有边或无边。邻接矩阵的增删查操作效率很高，但占用空间大。 -- 邻接表使用多个链表来表示图，第 $i$ 条链表对应顶点 $i$ ，其中存储了该顶点的所有邻接顶点。邻接表相对邻接矩阵更加节省空间，但由于需要通过遍历链表来查找边，因此时间效率较低。 -- 当邻接表中的链表过长时，可以将其转化为红黑树或哈希表，从而提升查询效率。 -- 从算法思想角度分析，邻接矩阵体现“以空间换时间”，邻接表体现“以时间换空间” -- 图可以用于建模各类现实系统，例如社交网络、地铁线路等。 +- 图由顶点和边组成，可以被表示为一组顶点和一组边构成的集合。 +- 相较于线性关系（链表）和分治关系（树），网络关系（图）具有更高的自由度，因而更为复杂。 +- 有向图的边具有方向性，连通图中的任意顶点均可达，有权图的每条边都包含权重变量。 +- 邻接矩阵利用矩阵来表示图，每一行（列）代表一个顶点，矩阵元素代表边，用 $1$ 或 $0$ 表示两个顶点之间有边或无边。邻接矩阵在增删查操作上效率很高，但空间占用较多。 +- 邻接表使用多个链表来表示图，第 $i$ 条链表对应顶点 $i$ ，其中存储了该顶点的所有邻接顶点。邻接表相对于邻接矩阵更加节省空间，但由于需要遍历链表来查找边，时间效率较低。 +- 当邻接表中的链表过长时，可以将其转换为红黑树或哈希表，从而提升查询效率。 +- 从算法思想角度分析，邻接矩阵体现“以空间换时间”，邻接表体现“以时间换空间”。 +- 图可用于建模各类现实系统，如社交网络、地铁线路等。 - 树是图的一种特例，树的遍历也是图的遍历的一种特例。 -- 图的广度优先遍历是一种由近及远、层层扩张的搜索方式，常借助队列实现。 -- 图的深度优先遍历是一种优先走到底、无路可走再回头的搜索方式，常基于递归来实现。 +- 图的广度优先遍历是一种由近及远、层层扩张的搜索方式，通常借助队列实现。 +- 图的深度优先遍历是一种优先走到底、无路可走时再回溯的搜索方式，常基于递归来实现。 diff --git a/docs/chapter_hashing/hash_collision.md b/docs/chapter_hashing/hash_collision.md index 0276177a1..1ebf444f1 100644 --- a/docs/chapter_hashing/hash_collision.md +++ b/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 个键值对，超出容量则连接一个溢出桶；当溢出桶过多时，会执行一次特殊的等量扩容操作，以确保性能。 diff --git a/docs/chapter_hashing/hash_map.md b/docs/chapter_hashing/hash_map.md index 04063d96b..5c096212e 100755 --- a/docs/chapter_hashing/hash_map.md +++ b/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)$，全面胜出！
@@ -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)$ 时间复杂度； +- 较高的空间利用率，即使“键值对占用空间 / 哈希表总占用空间”比例最大化； diff --git a/docs/chapter_hashing/summary.md b/docs/chapter_hashing/summary.md index 8af104211..7026155cb 100644 --- a/docs/chapter_hashing/summary.md +++ b/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 采用开放寻址。