yetao
/
hello-algo
mirror of https://github.com/krahets/hello-algo.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

build

Browse Source
pull/944/head
krahets 2 years ago
parent d4622e0ecb
commit adcbab4d4c
11 changed files with 152 additions and 152 deletions
Show Stats Download Patch File Download Diff File

28
chapter_appendix/contribution.md
Unescape View File

@ -6,37 +6,37 @@ comments: true
!!! success "开源的魅力" !!! success "开源的魅力"
纸质书籍的两次印刷的间隔时间往往需要数年，内容更新非常不方便。</br>但在本开源 HTML 书中，内容更迭的时间被缩短至数日甚至几个小时。 纸质书籍的两次印刷的间隔时间往往需要数年，内容更新非常不方便。</br>但在本开源书中，内容更迭的时间被缩短至数日甚至几个小时。
由于作者水平有限，书中内容难免疏漏谬误，请您谅解。如果发现笔误、无效链接、内容缺失、文字歧义、解释不清晰、行文结构不合理等问题，请您帮忙修正，以帮助其他读者获取更优质的学习内容。所有[撰稿人](https://github.com/krahets/hello-algo/graphs/contributors)将被展示在仓库与网站主页，以感谢他们对开源社区的无私奉献！ 由于作者能力有限，书中难免存在一些遗漏和错误，请您谅解。如果您发现了笔误、失效链接、内容缺失、文字歧义、解释不清晰或行文结构不合理等问题，请协助我们进行修正，以帮助其他读者获得更优质的学习资源。所有[撰稿人](https://github.com/krahets/hello-algo/graphs/contributors)将在仓库和网站主页上展示，以感谢他们对开源社区的无私奉献！
## 12.2.1. &nbsp; 内容微调 ## 12.2.1. &nbsp; 内容微调
每个页面的右上角都有一个「编辑」图标，你可以按照以下步骤修改文字或代码： 在每个页面的右上角有一个「编辑」图标，您可以按照以下步骤修改文本或代码：
1. 点击编辑按钮，如果遇到提示“需要 Fork 此仓库”，请通过； 1. 点击编辑按钮，如果遇到“需要 Fork 此仓库”的提示，请同意该操作；
2. 修改 Markdown 源文件内容，并检查内容正确性，尽量保持排版格式统一； 2. 修改 Markdown 源文件内容，并确保内容正确，同时尽量保持排版格式的统一；
3. 在页面底部填写更改说明，然后单击“Propose file change”按钮；页面跳转后，点击“Create pull request”按钮发起拉取请求即可。 3. 在页面底部填写修改说明，然后点击“Propose file change”按钮；页面跳转后，点击“Create pull request”按钮即可发起拉取请求。
![页面编辑按键](contribution.assets/edit_markdown.png) ![页面编辑按键](contribution.assets/edit_markdown.png)
<p align="center"> Fig. 页面编辑按键 </p> <p align="center"> Fig. 页面编辑按键 </p>
图片无法直接修改，需要通过新建 [Issue](https://github.com/krahets/hello-algo/issues) 或评论留言来描述图片问题，我会第一时间重新画图并替换图片。 由于图片无法直接修改，因此需要通过新建 [Issue](https://github.com/krahets/hello-algo/issues) 或评论留言来描述图片问题，我们会尽快重新绘制并替换图片。
## 12.2.2. &nbsp; 内容创作 ## 12.2.2. &nbsp; 内容创作
如果您想要参与本开源项目，包括翻译代码至其他编程语言、拓展文章内容等，那么需要实施 Pull Request 工作流程： 如果您有兴趣参与此开源项目，包括将代码翻译成其他编程语言、扩展文章内容等，那么需要实施 Pull Request 工作流程：
1. 登录 GitHub ，并 Fork [本仓库](https://github.com/krahets/hello-algo) 至个人账号； 1. 登录 GitHub ，将[本仓库](https://github.com/krahets/hello-algo) Fork 到个人账号下；
2. 进入 Fork 仓库网页，使用 `git clone` 克隆该仓库至本地； 2. 进入您的 Fork 仓库网页，使用 git clone 命令将仓库克隆至本地；
3. 在本地进行内容创作，并通过运行测试来验证代码正确性； 3. 在本地进行内容创作，并通过运行测试以验证代码的正确性；
4. 将本地更改 Commit ，并 Push 至远程仓库； 4. 将本地所做更改 Commit ，然后 Push 至远程仓库；
5. 刷新仓库网页，点击“Create pull request”按钮发起拉取请求即可； 5. 刷新仓库网页，点击“Create pull request”按钮即可发起拉取请求；
## 12.2.3. &nbsp; Docker 部署 ## 12.2.3. &nbsp; Docker 部署
你可以使用 Docker 来部署本项目。稍等片刻，即可使用浏览器打开 `http://localhost:8000` 访问本项目。 我们可以通过 Docker 来部署本项目。执行以下脚本，稍等片刻后，即可使用浏览器打开 `http://localhost:8000` 来访问本项目。
```shell ```shell
git clone https://github.com/krahets/hello-algo.git git clone https://github.com/krahets/hello-algo.git

2
chapter_computational_complexity/space_complexity.md
Unescape View File

@ -1375,7 +1375,7 @@ $$
### 指数阶 $O(2^n)$ ### 指数阶 $O(2^n)$
指数阶常见于二叉树。高度为 $n$ 的「满二叉树」的节点数量为 $2^n - 1$ ，占用 $O(2^n)$ 空间。 指数阶常见于二叉树。高度为 $n$ 的「满二叉树」的结点数量为 $2^n - 1$ ，占用 $O(2^n)$ 空间。
=== "Java" === "Java"

4
chapter_computational_complexity/summary.md
Unescape View File

@ -13,8 +13,8 @@ comments: true
### 时间复杂度 ### 时间复杂度
- 时间复杂度用于衡量算法运行时间随数据量增长的趋势，可以有效评估算法效率，但在某些情况下可能失效，如在输入数据量较小或时间复杂度相同时，无法精确对比算法效率的优劣。 - 时间复杂度用于衡量算法运行时间随数据量增长的趋势，可以有效评估算法效率，但在某些情况下可能失效，如在输入数据量较小或时间复杂度相同时，无法精确对比算法效率的优劣。
- 最差时间复杂度使用大 $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!)$ 等。 - 常见时间复杂度从小到大排列有 $O(1)$ , $O(\log n)$ , $O(n)$ , $O(n \log n)$ , $O(n^2)$ , $O(2^n)$ , $O(n!)$ 等。
- 某些算法的时间复杂度非固定，而是与输入数据的分布有关。时间复杂度分为最差、最佳、平均时间复杂度，最佳时间复杂度几乎不用，因为输入数据一般需要满足严格条件才能达到最佳情况。 - 某些算法的时间复杂度非固定，而是与输入数据的分布有关。时间复杂度分为最差、最佳、平均时间复杂度，最佳时间复杂度几乎不用，因为输入数据一般需要满足严格条件才能达到最佳情况。
- 平均时间复杂度反映算法在随机数据输入下的运行效率，最接近实际应用中的算法性能。计算平均时间复杂度需要统计输入数据分布以及综合后的数学期望。 - 平均时间复杂度反映算法在随机数据输入下的运行效率，最接近实际应用中的算法性能。计算平均时间复杂度需要统计输入数据分布以及综合后的数学期望。

52
chapter_graph/graph.md
Unescape View File

@ -4,7 +4,7 @@ comments: true
# 9.1. &nbsp; 图 # 9.1. &nbsp; 图
「图 Graph」是一种非线性数据结构，由「顶点 Vertex」和「边 Edge」组成。我们可将图 $G$ 抽象地表示为一组顶点 $V$ 和一组边 $E$ 的集合。例如，以下表示一个包含 5 个顶点和 7 条边的图 「图 Graph」是一种非线性数据结构，由「顶点 Vertex」和「边 Edge」组成。我们可以将图 $G$ 抽象地表示为一组顶点 $V$ 和一组边 $E$ 的集合。以下示例展示了一个包含 5 个顶点和 7 条边的图。
$$ $$
\begin{aligned} \begin{aligned}
@ -18,20 +18,20 @@ $$
<p align="center"> Fig. 链表、树、图之间的关系 </p> <p align="center"> Fig. 链表、树、图之间的关系 </p>
那么，图与其他数据结构的关系是什么？如果我们把「顶点」看作结点，把「边」看作连接各个结点的指针，则可将「图」看成一种从「链表」拓展而来的数据结构。**相比线性关系（链表）和分治关系（树），网络关系（图）的自由度更高，也从而更为复杂**。 那么，图与其他数据结构的关系是什么？如果我们把「顶点」看作结点，把「边」看作连接各个结点的指针，则可将「图」看作是一种从「链表」拓展而来的数据结构。**相较于线性关系（链表）和分治关系（树），网络关系（图）的自由度更高，从而更为复杂**。
## 9.1.1. &nbsp; 图常见类型 ## 9.1.1. &nbsp; 图常见类型
根据边是否有方向，分为「无向图 Undirected Graph」和「有向图 Directed Graph」。 根据边是否具有方向，可分为「无向图 Undirected Graph」和「有向图 Directed Graph」。
- 在无向图中，边表示两顶点之间“双向”的连接关系，例如微信或 QQ 中的“好友关系”； - 在无向图中，边表示两顶点之间的“双向”连接关系，例如微信或 QQ 中的“好友关系”；
- 在有向图中，边是有方向的，即 $A \rightarrow B$ 和 $A \leftarrow B$ 两个方向的边是相互独立的，例如微博或抖音上的“关注”与“被关注”关系； - 在有向图中，边具有方向性，即 $A \rightarrow B$ 和 $A \leftarrow B$ 两个方向的边是相互独立的，例如微博或抖音上的“关注”与“被关注”关系；
![有向图与无向图](graph.assets/directed_graph.png) ![有向图与无向图](graph.assets/directed_graph.png)
<p align="center"> Fig. 有向图与无向图 </p> <p align="center"> Fig. 有向图与无向图 </p>
根据所有顶点是否连通，分为「连通图 Connected Graph」和「非连通图 Disconnected Graph」。 根据所有顶点是否连通，可分为「连通图 Connected Graph」和「非连通图 Disconnected Graph」。
- 对于连通图，从某个顶点出发，可以到达其余任意顶点； - 对于连通图，从某个顶点出发，可以到达其余任意顶点；
- 对于非连通图，从某个顶点出发，至少有一个顶点无法到达； - 对于非连通图，从某个顶点出发，至少有一个顶点无法到达；
@ -40,7 +40,7 @@ $$
<p align="center"> Fig. 连通图与非连通图 </p> <p align="center"> Fig. 连通图与非连通图 </p>
我们可以给边添加“权重”变量，得到「有权图 Weighted Graph」。例如，在王者荣耀等游戏中，系统会根据共同游戏时间来计算玩家之间的“亲密度”，这种亲密度网络就可以使用有权图来表示。 我们还可以为边添加“权重”变量，从而得到「有权图 Weighted Graph」。例如，在王者荣耀等手游中，系统会根据共同游戏时间来计算玩家之间的“亲密度”，这种亲密度网络就可以用有权图来表示。
![有权图与无权图](graph.assets/weighted_graph.png) ![有权图与无权图](graph.assets/weighted_graph.png)
@ -48,31 +48,31 @@ $$
## 9.1.2. &nbsp; 图常用术语 ## 9.1.2. &nbsp; 图常用术语
- 「邻接 Adjacency」：当两顶点之间有边相连时，称此两顶点“邻接”。例如，上图中顶点 1 的邻接顶点为顶点 2, 3, 5 。 - 「邻接 Adjacency」：当两顶点之间存在边相连时，称这两顶点“邻接”。在上图中，顶点 1 的邻接顶点为顶点 2、3、5。
- 「路径 Path」：从顶点 A 到顶点 B 走过的边构成的序列，被称为从 A 到 B 的“路径”。例如，上图中边序列 1-5-2-4 是顶点 1 到顶点 4 的一个路径。 - 「路径 Path」：从顶点 A 到顶点 B 经过的边构成的序列被称为从 A 到 B 的“路径”。在上图中，边序列 1-5-2-4 是顶点 1 到顶点 4 的一条路径。
- 「度 Degree」表示一个顶点具有多少条边。对于有向图，「入度 In-Degree」表示有多少条边指向该顶点，「出度 Out-Degree」表示有多少条边从该顶点指出。 - 「度 Degree」表示一个顶点拥有的边数。对于有向图，「入度 In-Degree」表示有多少条边指向该顶点，「出度 Out-Degree」表示有多少条边从该顶点指出。
## 9.1.3. &nbsp; 图的表示 ## 9.1.3. &nbsp; 图的表示
图的常用表示方法有「邻接矩阵」和「邻接表」。以下使用「无向图」来举例。 图的常用表示方法包括「邻接矩阵」和「邻接表」。以下使用无向图进行举例。
### 邻接矩阵 ### 邻接矩阵
设图的顶点数量为 $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) ![图的邻接矩阵表示](graph.assets/adjacency_matrix.png)
<p align="center"> Fig. 图的邻接矩阵表示 </p> <p align="center"> Fig. 图的邻接矩阵表示 </p>
邻接矩阵具有以下性质： 邻接矩阵具有以下特性：
- 顶点不能与自身相连，因而邻接矩阵主对角线元素没有意义。 - 顶点不能与自身相连，因此邻接矩阵主对角线元素没有意义。
- 「无向图」两个方向的边等价，此时邻接矩阵关于主对角线对称。 - 对于无向图，两个方向的边等价，此时邻接矩阵关于主对角线对称。
- 将邻接矩阵的元素从 $1$ , $0$ 替换为权重，则能够表示「有权图」。 - 将邻接矩阵的元素从 $1$ , $0$ 替换为权重，则可表示有权图。
使用邻接矩阵表示图时，我们可以直接通过访问矩阵元素来获取边，因此增删查操作的效率很高，时间复杂度均为 $O(1)$ 。然而，矩阵的空间复杂度为 $O(n^2)$ ，内存占用较大。 使用邻接矩阵表示图时，我们可以直接访问矩阵元素以获取边，因此增删查操作的效率很高，时间复杂度均为 $O(1)$ 。然而，矩阵的空间复杂度为 $O(n^2)$ ，内存占用较多。
### 邻接表 ### 邻接表
@ -82,20 +82,20 @@ $$
<p align="center"> Fig. 图的邻接表表示 </p> <p align="center"> Fig. 图的邻接表表示 </p>
邻接表仅存储存在的边，而边的总数往往远小于 $n^2$ ，因此更加节省空间。但是，因为在邻接表中需要通过遍历链表来查找边，所以其时间效率不如邻接矩阵。 邻接表仅存储实际存在的边，而边的总数通常远小于 $n^2$ ，因此它更加节省空间。然而，在邻接表中需要通过遍历链表来查找边，因此其时间效率不如邻接矩阵。
观察上图发现，**邻接表结构与哈希表「链地址法」非常相似，因此我们也可以用类似方法来优化效率**。比如，当链表较长时，可以把链表转化为 AVL 树或红黑树，从而将时间效率从 $O(n)$ 优化至 $O(\log n)$ ，还可以通过中序遍历获取有序序列；还可以将链表转化为哈希表，将时间复杂度降低至 $O(1)$ 。 观察上图可发现，**邻接表结构与哈希表中的「链地址法」非常相似，因此我们也可以采用类似方法来优化效率**。例如，当链表较长时，可以将链表转化为 AVL 树或红黑树，从而将时间效率从 $O(n)$ 优化至 $O(\log n)$ ，还可以通过中序遍历获取有序序列；此外，还可以将链表转换为哈希表，将时间复杂度降低至 $O(1)$ 。
## 9.1.4. &nbsp; 图常见应用 ## 9.1.4. &nbsp; 图常见应用
现实中的许多系统都可以使用图来建模，对应的待求解问题也可以被约化为图计算问题。 实际应用中，许多系统都可以用图来建模，相应的待求解问题也可以约化为图计算问题。
<div class="center-table" markdown> <div class="center-table" markdown>
| | 顶点 | 边 | 图计算问题 | | | 顶点 | 边 | 图计算问题 |
| -------- | ---- | -------------------- | ------------ | | ------ | ---- | --------------- | ------------ |
| 社交网络 | 用户 | 好友关系 | 潜在好友推荐 | | 社交网络 | 用户 | 好友关系 | 潜在好友推荐 |
| 地铁线路 | 站点 | 站点间的连通性 | 最短路线推荐 | | 地铁线路 | 站点 | 站点间的连通性 | 最短路线推荐 |
| 太阳系 | 星体 | 星体间的万有引力作用 | 行星轨道计算 | | 太阳系 | 星体 | 星体间的万有引力作用 | 行星轨道计算 |
</div> </div>

24
chapter_graph/graph_operations.md
Unescape View File

@ -4,13 +4,13 @@ comments: true
# 9.2. &nbsp; 图基础操作 # 9.2. &nbsp; 图基础操作
图的基础操作分为对「边」的操作和对「顶点」的操作，在「邻接矩阵」和「邻接表」这两种表示下的实现方式不同。 图的基础操作可分为对「边」的操作和对「顶点」的操作。在「邻接矩阵」和「邻接表」两种表示方法下，实现方式有所不同。
## 9.2.1. &nbsp; 基于邻接矩阵的实现 ## 9.2.1. &nbsp; 基于邻接矩阵的实现
设图的顶点总数为 $n$ ，则有： 给定一个顶点数量为 $n$ 的无向图，则有：
- **添加或删除边**：直接在邻接矩阵中修改指定边的对应元素即可，使用 $O(1)$ 时间。而由于是无向图，因此需要同时更新两个方向的边。 - **添加或删除边**：直接在邻接矩阵中修改指定的边即可，使用 $O(1)$ 时间。而由于是无向图，因此需要同时更新两个方向的边。
- **添加顶点**：在邻接矩阵的尾部添加一行一列，并全部填 $0$ 即可，使用 $O(n)$ 时间。 - **添加顶点**：在邻接矩阵的尾部添加一行一列，并全部填 $0$ 即可，使用 $O(n)$ 时间。
- **删除顶点**：在邻接矩阵中删除一行一列。当删除首行首列时达到最差情况，需要将 $(n-1)^2$ 个元素“向左上移动”，从而使用 $O(n^2)$ 时间。 - **删除顶点**：在邻接矩阵中删除一行一列。当删除首行首列时达到最差情况，需要将 $(n-1)^2$ 个元素“向左上移动”，从而使用 $O(n^2)$ 时间。
- **初始化**：传入 $n$ 个顶点，初始化长度为 $n$ 的顶点列表 `vertices` ，使用 $O(n)$ 时间；初始化 $n \times n$ 大小的邻接矩阵 `adjMat` ，使用 $O(n^2)$ 时间。 - **初始化**：传入 $n$ 个顶点，初始化长度为 $n$ 的顶点列表 `vertices` ，使用 $O(n)$ 时间；初始化 $n \times n$ 大小的邻接矩阵 `adjMat` ，使用 $O(n^2)$ 时间。
@ -776,13 +776,13 @@ comments: true
## 9.2.2. &nbsp; 基于邻接表的实现 ## 9.2.2. &nbsp; 基于邻接表的实现
设图的顶点总数为 $n$ 、边总数为 $m$ ，则有： 设无向图的顶点总数为 $n$ 、边总数为 $m$ ，则有：
- **添加边**：在顶点对应链表的尾部添加边即可，使用 $O(1)$ 时间。因为是无向图，所以需要同时添加两个方向的边。 - **添加边**：在顶点对应链表的末尾添加边即可，使用 $O(1)$ 时间。因为是无向图，所以需要同时添加两个方向的边。
- **删除边**：在顶点对应链表中查询与删除指定边，使用 $O(m)$ 时间。与添加边一样，需要同时删除两个方向的边。 - **删除边**：在顶点对应链表中查找并删除指定边，使用 $O(m)$ 时间。在无向图中，需要同时删除两个方向的边。
- **添加顶点**：在邻接表中添加一个链表即可，并以新增顶点为链表头结点，使用 $O(1)$ 时间。 - **添加顶点**：在邻接表中添加一个链表，并将新增顶点作为链表头结点，使用 $O(1)$ 时间。
- **删除顶点**：需要遍历整个邻接表，删除包含指定顶点的所有边，使用 $O(n + m)$ 时间。 - **删除顶点**：需遍历整个邻接表，删除包含指定顶点的所有边，使用 $O(1)$ 时间。
- **初始化**：需要在邻接表中建立 $n$ 个结点和 $2m$ 条边，使用 $O(n + m)$ 时间。 - **初始化**：在邻接表中创建 $n$ 个顶点和 $2m$ 条边，使用 $O(n + m)$ 时间。
=== "初始化邻接表" === "初始化邻接表"
![邻接表的初始化、增删边、增删顶点](graph_operations.assets/adjacency_list_initialization.png) ![邻接表的初始化、增删边、增删顶点](graph_operations.assets/adjacency_list_initialization.png)
@ -799,10 +799,10 @@ comments: true
=== "删除顶点" === "删除顶点"
![adjacency_list_remove_vertex](graph_operations.assets/adjacency_list_remove_vertex.png) ![adjacency_list_remove_vertex](graph_operations.assets/adjacency_list_remove_vertex.png)
基于邻接表实现图的代码如下所示。细心的同学可能注意到，**我们在邻接表中使用 `Vertex` 结点类来表示顶点**，这样做的原因是： 以下是基于邻接表实现图的代码示例。细心的同学可能注意到，**我们在邻接表中使用 `Vertex` 结点类来表示顶点**，这样做的原因有：
- 如果我们选择通过顶点值来区分不同顶点，那么值重复的顶点将无法被区分。 - 如果我们选择通过顶点值来区分不同顶点，那么值重复的顶点将无法被区分。
- 如果类似邻接矩阵那样，使用顶点列表索引来区分不同顶点。那么，假设我们想要删除索引为 $i$ 的顶点，则需要遍历整个邻接表，将其中 $> i$ 的索引全部执行 $-1$ ，这样操作效率太低。 - 如果类似邻接矩阵那样，使用顶点列表索引来区分不同顶点。那么，假设我们想要删除索引为 $i$ 的顶点，则需要遍历整个邻接表，将其中 $> i$ 的索引全部减 $1$，这样操作效率较低。
- 因此我们考虑引入顶点类 `Vertex` ，使得每个顶点都是唯一的对象，此时删除顶点时就无需改动其余顶点了。 - 因此我们考虑引入顶点类 `Vertex` ，使得每个顶点都是唯一的对象，此时删除顶点时就无需改动其余顶点了。
=== "Java" === "Java"
@ -1471,4 +1471,4 @@ comments: true
</div> </div>
观察上表，貌似邻接表（哈希表）的时间与空间效率最优。但实际上，在邻接矩阵中操作边的效率更高，只需要一次数组访问或赋值操作即可。总结以上，**邻接矩阵体现“以空间换时间”，邻接表体现“以时间换空间”**。 观察上表，似乎邻接表（哈希表）的时间与空间效率最优。但实际上，在邻接矩阵中操作边的效率更高，只需要一次数组访问或赋值操作即可。综合来看，邻接矩阵体现了“以空间换时间”的原则，而邻接表体现了“以时间换空间”的原则。

36
chapter_graph/graph_traversal.md
Unescape View File

@ -6,15 +6,15 @@ comments: true
!!! note "图与树的关系" !!! 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。
## 9.3.1. &nbsp; 广度优先遍历 ## 9.3.1. &nbsp; 广度优先遍历
**广度优先遍历优是一种由近及远的遍历方式，从距离最近的顶点开始访问，并一层层向外扩张**。具体地，从某个顶点出发，先遍历该顶点的所有邻接顶点，随后遍历下个顶点的所有邻接顶点，以此类推…… **广度优先遍历是一种由近及远的遍历方式，从距离最近的顶点开始访问，并一层层向外扩张**。具体来说，从某个顶点出发，先遍历该顶点的所有邻接顶点，然后遍历下一个顶点的所有邻接顶点，以此类推，直至所有顶点访问完毕。
![图的广度优先遍历](graph_traversal.assets/graph_bfs.png) ![图的广度优先遍历](graph_traversal.assets/graph_bfs.png)
@ -22,11 +22,11 @@ comments: true
### 算法实现 ### 算法实现
BFS 常借助「队列」来实现。队列具有“先入先出”的性质，这与 BFS “由近及远”的思想是异曲同工的。 BFS 通常借助「队列」来实现。队列具有“先入先出”的性质，这与 BFS 的“由近及远”的思想异曲同工。
1. 将遍历起始顶点 `startVet` 加入队列，并开启循环； 1. 将遍历起始顶点 `startVet` 加入队列，并开启循环；
2. 在循环的每轮迭代中，弹出队首顶点弹出并记录访问，并将该顶点的所有邻接顶点加入到队列尾部； 2. 在循环的每轮迭代中，弹出队首顶点并记录访问，然后将该顶点的所有邻接顶点加入到队列尾部；
3. 循环 `2.` ，直到所有顶点访问完成后结束； 3. 循环步骤 `2.` ，直到所有顶点被访问完成后结束；
为了防止重复遍历顶点，我们需要借助一个哈希表 `visited` 来记录哪些结点已被访问。 为了防止重复遍历顶点，我们需要借助一个哈希表 `visited` 来记录哪些结点已被访问。
@ -299,17 +299,17 @@ BFS 常借助「队列」来实现。队列具有“先入先出”的性质，
!!! question "广度优先遍历的序列是否唯一？" !!! 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|)$ 空间。 **空间复杂度：** 列表 `res` ，哈希表 `visited` ，队列 `que` 中的顶点数量最多为 $|V|$ ，使用 $O(|V|)$ 空间。
## 9.3.2. &nbsp; 深度优先遍历 ## 9.3.2. &nbsp; 深度优先遍历
**深度优先遍历是一种优先走到底、无路可走再回头的遍历方式**。具体地，从某个顶点出发，不断地访问当前结点的某个邻接顶点，直到走到尽头时回溯，再继续走到底 + 回溯，以此类推……直至所有顶点遍历完成时结束。 **深度优先遍历是一种优先走到底、无路可走再回头的遍历方式**。具体地，从某个顶点出发，访问当前顶点的某个邻接顶点，直到走到尽头时返回，再继续走到尽头并返回，以此类推，直至所有顶点遍历完成。
![图的深度优先遍历](graph_traversal.assets/graph_dfs.png) ![图的深度优先遍历](graph_traversal.assets/graph_dfs.png)
@ -317,7 +317,7 @@ BFS 常借助「队列」来实现。队列具有“先入先出”的性质，
### 算法实现 ### 算法实现
这种“走到头 + 回溯”的算法形式一般基于递归来实现。与 BFS 类似，在 DFS 中我们也需要借助一个哈希表 `visited` 来记录已被访问的顶点，以避免重复访问顶点。 这种“走到尽头 + 回溯”的算法形式通常基于递归来实现。与 BFS 类似，在 DFS 中我们也需要借助一个哈希表 `visited` 来记录已被访问的顶点，以避免重复访问顶点。
=== "Java" === "Java"
@ -542,12 +542,12 @@ BFS 常借助「队列」来实现。队列具有“先入先出”的性质，
[class]{}-[func]{graphDFS} [class]{}-[func]{graphDFS}
``` ```
深度优先遍历的算法流程如下图所示，其中 深度优先遍历的算法流程如下图所示，其中：
- **直虚线代表向下递推**，代表开启了一个新的递归方法来访问新顶点； - **直虚线代表向下递推**，表示开启了一个新的递归方法来访问新顶点；
- **曲虚线代表向上回溯**，代表此递归方法已经返回，回溯到了开启此递归方法的位置； - **曲虚线代表向上回溯**，表示此递归方法已经返回，回溯到了开启此递归方法的位置；
为了加深理解，请你将图示与代码结合起来，在脑中（或者用笔画下来）模拟整个 DFS 过程，包括每个递归方法何时开启、何时返回。 为了加深理解，建议将图示与代码结合起来，在脑中（或者用笔画下来）模拟整个 DFS 过程，包括每个递归方法何时开启、何时返回。
=== "<1>" === "<1>"
![图的深度优先遍历步骤](graph_traversal.assets/graph_dfs_step1.png) ![图的深度优先遍历步骤](graph_traversal.assets/graph_dfs_step1.png)
@ -584,12 +584,12 @@ BFS 常借助「队列」来实现。队列具有“先入先出”的性质，
!!! question "深度优先遍历的序列是否唯一？" !!! 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|)$ 空间。 **空间复杂度：** 列表 `res` ，哈希表 `visited` 顶点数量最多为 $|V|$ ，递归深度最大为 $|V|$ ，因此使用 $O(|V|)$ 空间。

20
chapter_graph/summary.md
Unescape View File

@ -4,14 +4,14 @@ comments: true
# 9.4. &nbsp; 小结 # 9.4. &nbsp; 小结
- 图由顶点和边组成，可以表示为一组顶点和一组边构成的集合。 - 图由顶点和边组成，可以被表示为一组顶点和一组边构成的集合。
- 相比线性关系（链表）和分治关系（树），网络关系（图）的自由度更高，也从而更为复杂。 - 相较于线性关系（链表）和分治关系（树），网络关系（图）具有更高的自由度，因而更为复杂。
- 有向图的边存在方向，连通图中的任意顶点都可达，有权图的每条边都包含权重变量。 - 有向图的边具有方向性，连通图中的任意顶点均可达，有权图的每条边都包含权重变量。
- 邻接矩阵使用方阵来表示图，每一行（列）代表一个顶点，矩阵元素代表边，使用 $1$ 或 $0$ 来表示两个顶点之间有边或无边。邻接矩阵的增删查操作效率很高，但占用空间大。 - 邻接矩阵利用矩阵来表示图，每一行（列）代表一个顶点，矩阵元素代表边，用 $1$ 或 $0$ 表示两个顶点之间有边或无边。邻接矩阵在增删查操作上效率很高，但空间占用较多。
- 邻接表使用多个链表来表示图，第 $i$ 条链表对应顶点 $i$ ，其中存储了该顶点的所有邻接顶点。邻接表相对邻接矩阵更加节省空间，但由于需要通过遍历链表来查找边，因此时间效率较低。 - 邻接表使用多个链表来表示图，第 $i$ 条链表对应顶点 $i$ ，其中存储了该顶点的所有邻接顶点。邻接表相对于邻接矩阵更加节省空间，但由于需要遍历链表来查找边，时间效率较低。
- 当邻接表中的链表过长时，可以将其转化为红黑树或哈希表，从而提升查询效率。 - 当邻接表中的链表过长时，可以将其转换为红黑树或哈希表，从而提升查询效率。
- 从算法思想角度分析，邻接矩阵体现“以空间换时间”，邻接表体现“以时间换空间” - 从算法思想角度分析，邻接矩阵体现“以空间换时间”，邻接表体现“以时间换空间”。
- 图可以用于建模各类现实系统，例如社交网络、地铁线路等。 - 图可用于建模各类现实系统，如社交网络、地铁线路等。
- 树是图的一种特例，树的遍历也是图的遍历的一种特例。 - 树是图的一种特例，树的遍历也是图的遍历的一种特例。
- 图的广度优先遍历是一种由近及远、层层扩张的搜索方式，常借助队列实现。 - 图的广度优先遍历是一种由近及远、层层扩张的搜索方式，通常借助队列实现。
- 图的深度优先遍历是一种优先走到底、无路可走再回头的搜索方式，常基于递归来实现。 - 图的深度优先遍历是一种优先走到底、无路可走时再回溯的搜索方式，常基于递归来实现。

64
chapter_hashing/hash_collision.md
Unescape View File

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

32
chapter_hashing/hash_map.md
Unescape View File

@ -4,9 +4,9 @@ comments: true
# 6.1. &nbsp; 哈希表 # 6.1. &nbsp; 哈希表
哈希表通过建立「键 key」和「值 value」之间的映射，实现高效的元素查找。具体地，输入一个 key ，在哈希表中查询并获取 value ，时间复杂度为 $O(1)$ 。 哈希表通过建立「键 key」与「值 value」之间的映射，实现高效的元素查询。具体而言，我们向哈希表输入一个 key，则可以在 $O(1)$ 时间内获取对应的 value 。
例如，给定一个包含 $n$ 个学生的数据库，每个学生有“姓名 `name` ”和“学号 `id` ”两项数据，希望实现一个查询功能：**输入一个学号，返回对应的姓名**，则可以使用哈希表实现。 以一个包含 $n$ 个学生的数据库为例，每个学生都有“姓名 `name`”和“学号 `id`”两项数据。假如我们希望实现查询功能，例如“输入一个学号，返回对应的姓名”，则可以采用哈希表来实现。
![哈希表的抽象表示](hash_map.assets/hash_map.png) ![哈希表的抽象表示](hash_map.assets/hash_map.png)
@ -14,14 +14,14 @@ comments: true
## 6.1.1. &nbsp; 哈希表效率 ## 6.1.1. &nbsp; 哈希表效率
除了哈希表之外，还可以使用以下数据结构来实现上述查询功能： 除哈希表外，还可以使用以下数据结构来实现上述查询功能：
1. **无序数组**：每个元素为 `[学号, 姓名]` ； 1. **无序数组**：每个元素为 `[学号, 姓名]` ；
2. **有序数组**：将 `1.` 中的数组按照学号从小到大排序； 2. **有序数组**：将 `1.` 中的数组按照学号从小到大排序；
3. **链表**：每个结点的值为 `[学号, 姓名]` ； 3. **链表**：每个结点的值为 `[学号, 姓名]` ；
4. **二叉搜索树**：每个结点的值为 `[学号, 姓名]` ，根据学号大小来构建树； 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> <div class="center-table" markdown>
@ -396,18 +396,18 @@ comments: true
## 6.1.3. &nbsp; 哈希函数 ## 6.1.3. &nbsp; 哈希函数
哈希表的底层实现是数组，并且可能包含链表、二叉树（红黑树）等数据结构，以提升查询性能（下节会讨论）。 哈希表的底层实现为数组，同时可能包含链表、二叉树（红黑树）等数据结构，以提高查询性能（将在下节讨论）。
首先考虑最简单的情况，**仅用一个「数组」来实现哈希表**。根据习惯，我们将数组中的每个空位称为「桶 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)` ； 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 f(x) = x \% 100
@ -1273,20 +1273,20 @@ $$
## 6.1.4. &nbsp; 哈希冲突 ## 6.1.4. &nbsp; 哈希冲突
细心的同学可能会发现，**哈希函数 $f(x) = x \% 100$ 会在某些情况下失效**。具体地，当输入的 key 后两位相同时，哈希函数的计算结果也相同，指向同一个 value 。例如，分别查询两个学号 $12836$ 和 $20336$ ，则有 细心的你可能已经注意到，**在某些情况下，哈希函数 $f(x) = x % 100$ 可能无法正常工作**。具体来说，当输入的 key 后两位相同时，哈希函数的计算结果也会相同，从而指向同一个 value 。例如，查询学号为 $12836$ 和 $20336$ 的两个学生时，我们得到：
$$ $$
f(12836) = f(20336) = 36 f(12836) = f(20336) = 36
$$ $$
两个学号指向了同一个姓名，这明显是不对的，我们将这种现象称为「哈希冲突 Hash Collision」。如何避免哈希冲突的问题将被留在下章讨论。 这两个学号指向了同一个姓名，这显然是错误的。我们把这种情况称为「哈希冲突 Hash Collision」。在后续章节中，我们将讨论如何解决哈希冲突的问题。
![哈希冲突示例](hash_map.assets/hash_collision.png) ![哈希冲突示例](hash_map.assets/hash_collision.png)
<p align="center"> Fig. 哈希冲突示例 </p> <p align="center"> Fig. 哈希冲突示例 </p>
综上所述，一个优秀的「哈希函数」应该具备以下特性： 综上所述，一个优秀的哈希函数应具备以下特性：
- 尽量少地发生哈希冲突； - 尽可能减少哈希冲突的发生；
- 时间复杂度 $O(1)$ ，计算尽可能高效； - 查询效率高且稳定，能够在绝大多数情况下达到 $O(1)$ 时间复杂度；
- 空间使用率高，即“键值对占用空间 / 哈希表总占用空间”尽可能大； - 较高的空间利用率，即使“键值对占用空间 / 哈希表总占用空间”比例最大化；

18
chapter_hashing/summary.md
Unescape View File

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

24
chapter_heap/build_heap.md
Unescape View File

@ -4,19 +4,19 @@ comments: true
# 8.2. &nbsp; 建堆操作 * # 8.2. &nbsp; 建堆操作 *
如果我们想要根据输入列表来生成一个堆，这样的操作被称为「建堆」。 如果我们想要根据输入列表生成一个堆，这个过程被称为「建堆」。
## 8.2.1. &nbsp; 两种建堆方法 ## 8.2.1. &nbsp; 两种建堆方法
### 借助入堆方法实现 ### 借助入堆方法实现
最直接地，考虑借助「元素入堆」方法，先建立一个空堆，**再将列表元素依次入堆即可**。 最直接的方法是借助“元素入堆操作”实现，首先创建一个空堆，然后将列表元素依次添加到堆中。
设元素数量为 $n$ ，则最后一个元素入堆的时间复杂度为 $O(\log n)$ ，在依次入堆时，堆的平均长度为 $\frac{n}{2}$ ，因此该方法的总体时间复杂度为 $O(n \log n)$ 。 设元素数量为 $n$ ，则最后一个元素入堆的时间复杂度为 $O(\log n)$ 。在依次添加元素时，堆的平均长度为 $\frac{n}{2}$ ，因此该方法的总体时间复杂度为 $O(n \log n)$ 。
### 基于堆化操作实现 ### 基于堆化操作实现
有趣的是，存在一种更加高效的建堆方法，时间复杂度可以达到 $O(n)$ 。我们先将列表所有元素原封不动添加进堆，**然后迭代地对各个结点执行「从顶至底堆化」**。当然，**无需对叶结点执行堆化**，因为其没有子结点。 有趣的是，存在一种更高效的建堆方法，其时间复杂度仅为 $O(n)$ 。我们先将列表所有元素原封不动添加到堆中，**然后迭代地对各个结点执行“从顶至底堆化”**。当然，**我们不需要对叶结点执行堆化操作**，因为它们没有子结点。
=== "Java" === "Java"
@ -157,26 +157,26 @@ comments: true
## 8.2.2. &nbsp; 复杂度分析 ## 8.2.2. &nbsp; 复杂度分析
第二种建堆方法的时间复杂度为什么是 $O(n)$ 呢？我们来展开推算一下。 为什么第二种建堆方法的时间复杂度是 $O(n)$ ？我们来展开推算一下。
- 完全二叉树中，设结点总数为 $n$ ，则叶结点数量为 $(n + 1) / 2$ ，其中 $/$ 为向下整除。因此在排除叶结点后，需要堆化结点数量为 $(n - 1)/2$ ，即为 $O(n)$ ； - 完全二叉树中，设结点总数为 $n$ ，则叶结点数量为 $(n + 1) / 2$ ，其中 $/$ 为向下整除。因此，在排除叶结点后，需要堆化的结点数量为 $(n - 1)/2$ ，复杂度为 $O(n)$ ；
- 从顶至底堆化中，每个结点最多堆化至叶结点，因此最大迭代次数为二叉树高度 $O(\log n)$ ； - 在从顶至底堆化的过程中，每个结点最多堆化到叶结点，因此最大迭代次数为二叉树高度 $O(\log n)$ ；
将上述两者相乘，可得时间复杂度为 $O(n \log n)$ 。这个估算结果不够准确，因为我们没有考虑到 **二叉树底层结点远多于顶层结点** 的性质。 将上述两者相乘，可得到建堆过程的时间复杂度为 $O(n \log n)$。**然而，这个估算结果并不准确，因为我们没有考虑到二叉树底层结点数量远多于顶层结点的特性**。
下面我们来展开计算。为了减小计算难度，我们假设树是一个「完美二叉树」，该假设不会影响计算结果的正确性。设二叉树（即堆）结点数量为 $n$ ，树高度为 $h$ 。上文提到，**结点堆化最大迭代次数等于该结点到叶结点的距离，而这正是“结点高度”**。 接下来我们来进行更为详细的计算。为了减小计算难度，我们假设树是一个“完美二叉树”，该假设不会影响计算结果的正确性。设二叉树（即堆）结点数量为 $n$ ，树高度为 $h$ 。上文提到，**结点堆化最大迭代次数等于该结点到叶结点的距离，而该距离正是“结点高度”**。
![完美二叉树的各层结点数量](build_heap.assets/heapify_operations_count.png) ![完美二叉树的各层结点数量](build_heap.assets/heapify_operations_count.png)
<p align="center"> Fig. 完美二叉树的各层结点数量 </p> <p align="center"> Fig. 完美二叉树的各层结点数量 </p>
因此，我们将各层的“结点数量 $\times$ 结点高度”求和，即可得到 **所有结点的堆化的迭代次数总和**。 因此，我们可以将各层的“结点数量 $\times$ 结点高度”求和，**从而得到所有结点的堆化迭代次数的总和**。
$$ $$
T(h) = 2^0h + 2^1(h-1) + 2^2(h-2) + \cdots + 2^{(h-1)}\times1 T(h) = 2^0h + 2^1(h-1) + 2^2(h-2) + \cdots + 2^{(h-1)}\times1
$$ $$
化简上式需要借助中学的数列知识，先对 $T(h)$ 乘以 $2$ ，易得 化简上式需要借助中学的数列知识，先对 $T(h)$ 乘以 $2$ ，得到
$$ $$
\begin{aligned} \begin{aligned}
@ -191,7 +191,7 @@ $$
2T(h) - T(h) = T(h) = -2^0h + 2^1 + 2^2 + \cdots + 2^{h-1} + 2^h 2T(h) - T(h) = T(h) = -2^0h + 2^1 + 2^2 + \cdots + 2^{h-1} + 2^h
$$ $$
观察上式，$T(h)$ 是一个等比数列，可直接使用求和公式，得到时间复杂度为 观察上式，发现 $T(h)$ 是一个等比数列，可直接使用求和公式，得到时间复杂度为
$$ $$
\begin{aligned} \begin{aligned}

Write Preview
Loading…
Cancel
Save