diff --git a/docs/chapter_array_and_linkedlist/summary.md b/docs/chapter_array_and_linkedlist/summary.md index cb53d5ac0..b211db77c 100644 --- a/docs/chapter_array_and_linkedlist/summary.md +++ b/docs/chapter_array_and_linkedlist/summary.md @@ -2,7 +2,7 @@ - 数组和链表是两种基本数据结构，分别代表数据在计算机内存中的连续空间存储和离散空间存储方式。两者的优缺点呈现出互补的特性。 - 数组支持随机访问、占用内存较少；但插入和删除元素效率低，且初始化后长度不可变。 -- 链表通过更改指针实现高效的节点插入与删除，且可以灵活调整长度；但节点访问效率低、占用内存较多。常见的链表类型包括单向链表、循环链表、双向链表。 +- 链表通过更改引用（指针）实现高效的节点插入与删除，且可以灵活调整长度；但节点访问效率低、占用内存较多。常见的链表类型包括单向链表、循环链表、双向链表。 - 动态数组，又称列表，是基于数组实现的一种数据结构。它保留了数组的优势，同时可以灵活调整长度。列表的出现极大地提高了数组的易用性，但可能导致部分内存空间浪费。 - 下表总结并对比了数组与链表的各项特性与操作效率。 @@ -36,7 +36,7 @@ !!! question "为什么数组会强调要求相同类型的元素，而在链表中却没有强调同类型呢？" - 链表由结点组成，结点之间由指针连接，各个结点可以存储不同类型的数据，例如 int, double, string, object 等。 + 链表由结点组成，结点之间通过引用（指针）连接，各个结点可以存储不同类型的数据，例如 int, double, string, object 等。 相对地，数组元素则必须是相同类型的，这样才能通过计算偏移量来获取对应元素位置。例如，如果数组同时包含 int 和 long 两种类型，单个元素分别占用 4 bytes 和 8 bytes ，那么此时就不能用以下公式计算偏移量了，因为数组中包含了两种 `elementLength` 。 diff --git a/docs/chapter_backtracking/backtracking_algorithm.md b/docs/chapter_backtracking/backtracking_algorithm.md index c9ad1595c..405939b0d 100644 --- a/docs/chapter_backtracking/backtracking_algorithm.md +++ b/docs/chapter_backtracking/backtracking_algorithm.md @@ -2,11 +2,11 @@ 「回溯算法 Backtracking Algorithm」是一种通过穷举来解决问题的方法，它的核心思想是从一个初始状态出发，暴力搜索所有可能的解决方案，当遇到正确的解则将其记录，直到找到解或者尝试了所有可能的选择都无法找到解为止。 -回溯算法通常采用「深度优先搜索」来遍历解空间。在二叉树章节中，我们提到前序、中序和后序遍历都属于深度优先搜索。接下来我们先用前序遍历构造一个回溯问题，逐步了解回溯算法的工作原理。 +回溯算法通常采用「深度优先搜索」来遍历解空间。在二叉树章节中，我们提到前序、中序和后序遍历都属于深度优先搜索。接下来，我们利用前序遍历构造一个回溯问题，逐步了解回溯算法的工作原理。 !!! question "例题一" - 给定一个二叉树，搜索并记录所有值为 $7$ 的节点，返回节点列表。 + 给定一个二叉树，搜索并记录所有值为 $7$ 的节点，请返回节点列表。 对于此题，我们前序遍历这颗树，并判断当前节点的值是否为 $7$ ，若是则将该节点的值加入到结果列表 `res` 之中。 @@ -84,11 +84,11 @@ 对于例题一，访问每个节点都代表一次“尝试”，而越过叶结点或返回父节点的 `return` 则表示“回退”。 -值得说明的是，**回退并不等价于函数返回**。为解释这一点，我们对例题一稍作拓展。 +值得说明的是，**回退并不仅仅包括函数返回**。为解释这一点，我们对例题一稍作拓展。 !!! question "例题二" - 在二叉树中搜索所有值为 $7$ 的节点，**返回根节点到这些节点的路径**。 + 在二叉树中搜索所有值为 $7$ 的节点，**请返回根节点到这些节点的路径**。 在例题一代码的基础上，我们需要借助一个列表 `path` 记录访问过的节点路径。当访问到值为 $7$ 的节点时，则复制 `path` 并添加进结果列表 `res` 。遍历完成后，`res` 中保存的就是所有的解。 @@ -158,7 +158,9 @@ [class]{}-[func]{preOrder} ``` -在每次“尝试”中，我们通过将当前节点添加进 `path` 来记录路径；而在“回退”前，我们需要将该节点从 `path` 中弹出，**以恢复本次尝试之前的状态**。换句话说，**我们可以将尝试和回退理解为“前进”与“撤销”**，两个操作是互为相反的。 +在每次“尝试”中，我们通过将当前节点添加进 `path` 来记录路径；而在“回退”前，我们需要将该节点从 `path` 中弹出，**以恢复本次尝试之前的状态**。 + +观察该过程，**我们可以将尝试和回退理解为“前进”与“撤销”**，两个操作是互为逆向的。 === "<1>" ![尝试与回退](backtracking_algorithm.assets/preorder_find_paths_step1.png) @@ -199,12 +201,12 @@ !!! question "例题三" - 在二叉树中搜索所有值为 $7$ 的节点，返回根节点到这些节点的路径，**要求路径中有且只有一个值为 $7$ 的节点，并且不能包含值为 $3$ 的节点**。 + 在二叉树中搜索所有值为 $7$ 的节点，请返回根节点到这些节点的路径，**要求路径中只存在一个值为 $7$ 的节点，并且不允许有值为 $3$ 的节点**。 在例题二的基础上添加剪枝操作，包括： -- 当遇到值为 $7$ 的节点时，记录解并返回，终止搜索。 -- 当遇到值为 $3$ 的节点时，则直接返回，停止继续搜索。 +- 当遇到值为 $7$ 的节点时，记录解并返回，停止搜索。 +- 当遇到值为 $3$ 的节点时，则直接返回，停止搜索。 === "Java" @@ -280,24 +282,24 @@ 为了更清晰地分析算法问题，我们总结一下回溯算法中常用术语的含义，并对照例题三给出对应示例。 -| 名词 | 定义 | 例题三 | -| ------------------- | ------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------- | -| 解 Solution | 解是满足问题特定条件的答案。回溯算法的目标是找到一个或多个满足条件的解 | 根节点到节点 $7$ 的所有路径，且路径中不包含值为 $3$ 的节点 | -| 状态 State | 状态表示问题在某一时刻的情况，包括已经做出的选择 | 当前已访问的节点路径，即 `path` 节点列表 | -| 约束条件 Constraint | 约束条件是问题中限制解的可行性的条件，通常用于剪枝 | 要求路径中不能包含值为 $3$ 的节点 | -| 尝试 Attempt | 尝试是在搜索过程中，根据当前状态和可用选择来探索解空间的过程。尝试包括做出选择，更新状态，检查是否为解 | 递归访问左（右）子节点，将节点添加进 `path` ，判断节点的值是否为 $7$ | -| 回退 Backtracking | 回退指在搜索中遇到到不满足约束条件或无法继续搜索的状态时，撤销前面做出的选择，回到上一个状态 | 当越过叶结点、结束结点访问、遇到值为 $3$ 的节点时终止搜索，函数返回 | -| 剪枝 Pruning | 剪枝是根据问题特性和约束条件避免无意义的搜索路径的方法，可提高搜索效率 | 当遇到值为 $3$ 的节点时，则终止继续搜索 | +| 名词 | 定义 | 例题三 | +| ------------------- | -------------------------------------------------------------------------- | -------------------------------------------------------------------- | +| 解 Solution | 解是满足问题特定条件的答案，可能有一个或多个 | 根节点到节点 $7$ 的满足约束条件的所有路径 | +| 约束条件 Constraint | 约束条件是问题中限制解的可行性的条件，通常用于剪枝 | 路径中不包含节点 $3$ ，只包含一个节点 $7$ | +| 状态 State | 状态表示问题在某一时刻的情况，包括已经做出的选择 | 当前已访问的节点路径，即 `path` 节点列表 | +| 尝试 Attempt | 尝试是根据可用选择来探索解空间的过程，包括做出选择，更新状态，检查是否为解 | 递归访问左（右）子节点，将节点添加进 `path` ，判断节点的值是否为 $7$ | +| 回退 Backtracking | 回退指遇到不满足约束条件的状态时，撤销前面做出的选择，回到上一个状态 | 当越过叶结点、结束结点访问、遇到值为 $3$ 的节点时终止搜索，函数返回 | +| 剪枝 Pruning | 剪枝是根据问题特性和约束条件避免无意义的搜索路径的方法，可提高搜索效率 | 当遇到值为 $3$ 的节点时，则终止继续搜索 | !!! tip - 解、状态、约束条件等术语是通用的，适用于回溯算法、动态规划、贪心算法等。 + 问题、解、状态等概念是通用的，在分治、回溯、动态规划、贪心等算法中都有涉及。 ## 框架代码 -回溯算法可用于解决许多搜索问题、约束满足问题和组合优化问题。为提升代码通用性，我们希望将回溯算法的“尝试、回退、剪枝”的主体框架提炼出来。 +接下来，我们尝试将回溯的“尝试、回退、剪枝”的主体框架提炼出来，提升代码的通用性。 -设 `state` 为问题的当前状态，`choices` 表示当前状态下可以做出的选择，则可得到以下回溯算法的框架代码。 +在以下框架代码中，`state` 表示问题的当前状态，`choices` 表示当前状态下可以做出的选择。 === "Java" @@ -551,7 +553,7 @@ } ``` -下面，我们尝试基于此框架来解决例题三。在例题三中，状态 `state` 是节点遍历路径，选择 `choices` 是当前节点的左子节点和右子节点，结果 `res` 是路径列表，实现代码如下所示。 +下面，我们基于框架代码来解决例题三：状态 `state` 为节点遍历路径，选择 `choices` 为当前节点的左子节点和右子节点，结果 `res` 是路径列表。 === "Java" @@ -729,7 +731,7 @@ [class]{}-[func]{backtrack} ``` -相较于基于前序遍历的实现代码，基于回溯算法框架的实现代码虽然显得啰嗦，但通用性更好。实际上，**所有回溯问题都可以在该框架下解决**。我们需要根据具体问题来定义 `state` 和 `choices` ，并实现框架中的各个方法。 +相比基于前序遍历的代码实现，基于回溯算法框架的代码实现虽然显得啰嗦，但通用性更好。实际上，**许多回溯问题都可以在该框架下解决**。我们只需根据具体问题来定义 `state` 和 `choices` ，并实现框架中的各个方法。 ## 优势与局限性 @@ -737,16 +739,18 @@ 然而，在处理大规模或者复杂问题时，**回溯算法的运行效率可能难以接受**。 -- 在最坏的情况下，回溯算法需要遍历解空间的所有可能解，所需时间很长。例如，求解 $n$ 皇后问题的时间复杂度可以达到 $O(n!)$ 。 -- 在每一次递归调用时，都需要保存当前的状态（例如选择路径、用于剪枝的辅助变量等），对于深度很大的递归，空间需求可能会变得非常大。 +- **时间**：回溯算法通常需要遍历状态空间的所有可能，时间复杂度可以达到指数阶或阶乘阶。 +- **空间**：在递归调用中需要保存当前的状态（例如路径、用于剪枝的辅助变量等），当深度很大时，空间需求可能会变得很大。 -即便如此，**回溯算法仍然是某些搜索问题和约束满足问题的最佳解决方案**。对于这些问题，由于无法预测哪些选择可生成有效的解，因此我们必须对所有可能的选择进行遍历。在这种情况下，**关键是如何进行效率优化**： +即便如此，**回溯算法仍然是某些搜索问题和约束满足问题的最佳解决方案**。对于这些问题，由于无法预测哪些选择可生成有效的解，因此我们必须对所有可能的选择进行遍历。在这种情况下，**关键是如何进行效率优化**，常见方法有： -- 上文介绍过的剪枝是一种常用的优化方法。它可以避免搜索那些肯定不会产生有效解的路径，从而节省时间和空间。 -- 另一个常用的优化方法是加入「启发式搜索 Heuristic Search」策略，它在搜索过程中引入一些策略或者估计值，从而优先搜索最有可能产生有效解的路径。 +- **剪枝**：避免搜索那些肯定不会产生解的路径，从而节省时间和空间。 +- **启发式搜索**：在搜索过程中引入一些策略或者估计值，从而优先搜索最有可能产生有效解的路径。 ## 回溯典型例题 +回溯算法可用于解决许多搜索问题、约束满足问题和组合优化问题。 + **搜索问题**：这类问题的目标是找到满足特定条件的解决方案。 - 全排列问题：给定一个集合，求出其所有可能的排列组合。 @@ -765,4 +769,8 @@ - 旅行商问题：在一个图中，从一个点出发，访问所有其他点恰好一次后返回起点，求最短路径。 - 最大团问题：给定一个无向图，找到最大的完全子图，即子图中的任意两个顶点之间都有边相连。 -请注意，回溯算法通常不是解决组合优化问题的最优方法。0-1 背包问题通常使用动态规划解决；旅行商是一个 NP-Hard 问题，常用解决方法有遗传算法和蚁群算法等；最大团问题是图轮中的一个经典 NP-Hard 问题，通常用贪心算法等启发式算法来解决。 +请注意，对于许多组合优化问题，回溯都不是最优解决方案，例如： + +- 0-1 背包问题通常使用动态规划解决，以达到更高的时间效率； +- 旅行商是一个著名的 NP-Hard 问题，常用解法有遗传算法和蚁群算法等； +- 最大团问题是图论中的一个经典问题，可用贪心等启发式算法来解决； diff --git a/docs/chapter_backtracking/n_queens_problem.md b/docs/chapter_backtracking/n_queens_problem.md index e33a66169..1a58069ad 100644 --- a/docs/chapter_backtracking/n_queens_problem.md +++ b/docs/chapter_backtracking/n_queens_problem.md @@ -8,33 +8,37 @@ ![4 皇后问题的解](n_queens_problem.assets/solution_4_queens.png) -本题共有三个约束条件：**多个皇后不能在同一行、同一列和同一对角线**。值得注意的是，对角线分为主对角线 `\` 和副对角线 `/` 两种。 +本题共包含三个约束条件：**多个皇后不能在同一行、同一列、同一对角线**。值得注意的是，对角线分为主对角线 `\` 和次对角线 `/` 两种。 ![n 皇后问题的约束条件](n_queens_problem.assets/n_queens_constraints.png) -### 皇后放置策略 +### 逐行放置策略 -皇后的数量和棋盘的行数都为 $n$ ，因此我们容易得到第一个推论：**棋盘每行都允许且只允许放置一个皇后**。这意味着，我们可以采取逐行放置策略：从第一行开始，在每行放置一个皇后，直至最后一行结束。**此策略起到了剪枝的作用**，它避免了同一行出现多个皇后的所有搜索分支。 +皇后的数量和棋盘的行数都为 $n$ ，因此我们容易得到一个推论：**棋盘每行都允许且只允许放置一个皇后**。 -下图展示了 $4$ 皇后问题的逐行放置过程。受篇幅限制，下图仅展开了第一行的一个搜索分支。在搜索过程中，我们将不满足列约束和对角线约束的方案都剪枝了。 +也就是说，我们可以采取逐行放置策略：从第一行开始，在每行放置一个皇后，直至最后一行结束。 + +如下图所示，为 $4$ 皇后问题的逐行放置过程。受画幅限制，下图仅展开了第一行的其中一个搜索分支，并且将不满足列约束和对角线约束的方案都进行了剪枝。 ![逐行放置策略](n_queens_problem.assets/n_queens_placing.png) +本质上看，**逐行放置策略起到了剪枝的作用**，它避免了同一行出现多个皇后的所有搜索分支。 + ### 列与对角线剪枝 -为了实现根据列约束剪枝，我们可以利用一个长度为 $n$ 的布尔型数组 `cols` 记录每一列是否有皇后。在每次决定放置前，我们通过 `cols` 将已有皇后的列剪枝，并在回溯中动态更新 `cols` 的状态。 +为了满足列约束，我们可以利用一个长度为 $n$ 的布尔型数组 `cols` 记录每一列是否有皇后。在每次决定放置前，我们通过 `cols` 将已有皇后的列进行剪枝，并在回溯中动态更新 `cols` 的状态。 -那么，如何处理对角线约束呢？设棋盘中某个格子的行列索引为 `(row, col)` ，观察矩阵的某条主对角线，**我们发现该对角线上所有格子的行索引减列索引相等**，即 `row - col` 为恒定值。换句话说，若两个格子满足 `row1 - col1 == row2 - col2` ，则这两个格子一定处在一条主对角线上。 +那么，如何处理对角线约束呢？设棋盘中某个格子的行列索引为 $(row, col)$ ，选定矩阵中的某条主对角线，我们发现该对角线上所有格子的行索引减列索引都相等，**即对角线上所有格子的 $row - col$ 为恒定值**。 -利用该性质，我们可以借助一个数组 `diag1` 来记录每条主对角线上是否有皇后。注意，$n$ 维方阵 `row - col` 的范围是 $[-n + 1, n - 1]$ ，因此共有 $2n - 1$ 条主对角线。 +也就是说，如果两个格子满足 $row_1 - col_1 = row_2 - col_2$ ，则它们一定处在同一条主对角线上。利用该规律，我们可以借助一个数组 `diag1` 来记录每条主对角线上是否有皇后。 -![处理列约束和对角线约束](n_queens_problem.assets/n_queens_cols_diagonals.png) +同理，**次对角线上的所有格子的 $row + col$ 是恒定值**。我们可以使用相同方法，借助数组 `diag2` 来处理次对角线约束。 -同理，**次对角线上的所有格子的 `row + col` 是恒定值**。我们可以使用同样的方法，借助数组 `diag2` 来处理次对角线约束。 +![处理列约束和对角线约束](n_queens_problem.assets/n_queens_cols_diagonals.png) ### 代码实现 -根据以上分析，我们便可以写出 $n$ 皇后的解题代码。 +请注意，$n$ 维方阵中 $row - col$ 的范围是 $[-n + 1, n - 1]$ ，$row + col$ 的范围是 $[0, 2n - 2]$ ，所以主对角线和次对角线的数量都为 $2n - 1$ ，即数组 `diag1` 和 `diag2` 的长度都为 $2n - 1$ 。 === "Java" @@ -124,8 +128,6 @@ [class]{}-[func]{nQueens} ``` -### 复杂度分析 - 逐行放置 $n$ 次，考虑列约束，则从第一行到最后一行分别有 $n, n-1, \cdots, 2, 1$ 个选择，**因此时间复杂度为 $O(n!)$** 。实际上，根据对角线约束的剪枝也能够大幅地缩小搜索空间，因而搜索效率往往优于以上时间复杂度。 -`state` 使用 $O(n^2)$ 空间，`cols` , `diags1` , `diags2` 皆使用 $O(n)$ 空间。最大递归深度为 $n$ ，使用 $O(n)$ 栈帧空间。因此，**空间复杂度为 $O(n^2)$** 。 +数组 `state` 使用 $O(n^2)$ 空间，数组 `cols` , `diags1` , `diags2` 皆使用 $O(n)$ 空间。最大递归深度为 $n$ ，使用 $O(n)$ 栈帧空间。因此，**空间复杂度为 $O(n^2)$** 。 diff --git a/docs/chapter_backtracking/permutations_problem.md b/docs/chapter_backtracking/permutations_problem.md index c0c53c7a9..a3f5f768b 100644 --- a/docs/chapter_backtracking/permutations_problem.md +++ b/docs/chapter_backtracking/permutations_problem.md @@ -20,14 +20,27 @@ 输入一个整数数组，数组中不包含重复元素，返回所有可能的排列。 -**从回溯算法的角度看，我们可以把生成排列的过程想象成一系列选择的结果**。假设输入数组为 $[1, 2, 3]$ ，如果我们先选择 $1$ 、再选择 $3$ 、最后选择 $2$ ，则获得排列 $[1, 3, 2]$ 。回退表示撤销一个选择，之后继续尝试其他选择。 +从回溯算法的角度看，**我们可以把生成排列的过程想象成一系列选择的结果**。假设输入数组为 $[1, 2, 3]$ ，如果我们先选择 $1$ 、再选择 $3$ 、最后选择 $2$ ，则获得排列 $[1, 3, 2]$ 。回退表示撤销一个选择，之后继续尝试其他选择。 -从回溯算法代码的角度看，候选集合 `choices` 是输入数组中的所有元素，状态 `state` 是直至目前已被选择的元素。注意，每个元素只允许被选择一次，**因此在遍历选择时，应当排除已经选择过的元素**。 +从回溯代码的角度看，候选集合 `choices` 是输入数组中的所有元素，状态 `state` 是直至目前已被选择的元素。请注意，每个元素只允许被选择一次，**因此 `state` 中的所有元素都应该是唯一的**。 如下图所示，我们可以将搜索过程展开成一个递归树，树中的每个节点代表当前状态 `state` 。从根节点开始，经过三轮选择后到达叶节点，每个叶节点都对应一个排列。 ![全排列的递归树](permutations_problem.assets/permutations_i.png) +### 重复选择剪枝 + +为了实现每个元素只被选择一次，我们考虑引入一个布尔型数组 `selected` ，其中 `selected[i]` 表示 `choices[i]` 是否已被选择。剪枝的实现原理为： + +- 在做出选择 `choice[i]` 后，我们就将 `selected[i]` 赋值为 $\text{True}$ ，代表它已被选择。 +- 遍历选择列表 `choices` 时，跳过所有已被选择过的节点，即剪枝。 + +如下图所示，假设我们第一轮选择 1 ，第二轮选择 3 ，第三轮选择 2 ，则需要在第二轮剪掉元素 1 的分支，在第三轮剪掉元素 1, 3 的分支。 + +![全排列剪枝示例](permutations_problem.assets/permutations_i_pruning.png) + +观察上图发现，该剪枝操作将搜索空间大小从 $O(n^n)$ 降低至 $O(n!)$ 。 + ### 代码实现 想清楚以上信息之后，我们就可以在框架代码中做“完形填空”了。为了缩短代码行数，我们不单独实现框架代码中的各个函数，而是将他们展开在 `backtrack()` 函数中。 @@ -120,29 +133,27 @@ [class]{}-[func]{permutationsI} ``` -### 重复选择剪枝 - -需要重点关注的是，我们引入了一个布尔型数组 `selected` ，它的长度与输入数组长度相等，其中 `selected[i]` 表示 `choices[i]` 是否已被选择。我们利用 `selected` 避免某个元素被重复选择，从而实现剪枝。 - -如下图所示，假设我们第一轮选择 1 ，第二轮选择 3 ，第三轮选择 2 ，则需要在第二轮剪掉元素 1 的分支，在第三轮剪掉元素 1, 3 的分支。**此剪枝操作可将搜索空间大小从 $O(n^n)$ 降低至 $O(n!)$** 。 - -![全排列剪枝示例](permutations_problem.assets/permutations_i_pruning.png) - ## 考虑相等元素的情况 !!! question 输入一个整数数组，**数组中可能包含重复元素**，返回所有不重复的排列。 -假设输入数组为 $[1, 1, 2]$ 。为了方便区分两个重复的元素 $1$ ，接下来我们将第二个元素记为 $\hat{1}$ 。如下图所示，上述方法生成的排列有一半都是重复的。 +假设输入数组为 $[1, 1, 2]$ 。为了方便区分两个重复元素 $1$ ，我们将第二个 $1$ 记为 $\hat{1}$ 。 + +如下图所示，上述方法生成的排列有一半都是重复的。 ![重复排列](permutations_problem.assets/permutations_ii.png) -那么，如何去除重复的排列呢？最直接地，我们可以借助一个哈希表，直接对排列结果进行去重。然而这样做不够优雅，**因为生成重复排列的搜索分支是没有必要的，应当被提前识别并剪枝**，这样可以进一步提升算法效率。 +那么如何去除重复的排列呢？最直接地，考虑借助一个哈希表，直接对排列结果进行去重。然而这样做不够优雅，**因为生成重复排列的搜索分支是没有必要的，应当被提前识别并剪枝**，这样可以进一步提升算法效率。 -观察发现，在第一轮中，选择 $1$ 或选择 $\hat{1}$ 是等价的，因为在这两个选择之下生成的所有排列都是重复的。因此，我们应该把 $\hat{1}$ 剪枝掉。同理，在第一轮选择 $2$ 后，第二轮选择中的 $1$ 和 $\hat{1}$ 也会产生重复分支，因此也需要将第二轮的 $\hat{1}$ 剪枝。 +### 相等元素剪枝 -本质上看，**我们的目标是实现在某一轮选择中，多个相等的元素仅被选择一次**。 +观察发现，在第一轮中，选择 $1$ 或选择 $\hat{1}$ 是等价的，在这两个选择之下生成的所有排列都是重复的。因此应该把 $\hat{1}$ 剪枝掉。 + +同理，在第一轮选择 $2$ 后，第二轮选择中的 $1$ 和 $\hat{1}$ 也会产生重复分支，因此也应将第二轮的 $\hat{1}$ 剪枝。 + +本质上看，**我们的目标是在某一轮选择中，保证多个相等的元素仅被选择一次**。 ![重复排列剪枝](permutations_problem.assets/permutations_ii_pruning.png) @@ -238,19 +249,17 @@ [class]{}-[func]{permutationsII} ``` +假设元素两两之间互不相同，则 $n$ 个元素共有 $n!$ 种排列（阶乘）；在记录结果时，需要复制长度为 $n$ 的列表，使用 $O(n)$ 时间。因此，**时间复杂度为 $O(n!n)$** 。 + +最大递归深度为 $n$ ，使用 $O(n)$ 栈帧空间。`selected` 使用 $O(n)$ 空间。同一时刻最多共有 $n$ 个 `duplicated` ，使用 $O(n^2)$ 空间。**因此空间复杂度为 $O(n^2)$** 。 + ### 两种剪枝对比 -注意，虽然 `selected` 和 `duplicated` 都起到剪枝的作用，但他们剪掉的是不同的分支： +请注意，虽然 `selected` 和 `duplicated` 都用作剪枝，但两者的目标不同： -- **剪枝条件一**：整个搜索过程中只有一个 `selected` 。它记录的是当前状态中包含哪些元素，作用是避免某个元素在 `state` 中重复出现。 -- **剪枝条件二**：每轮选择（即每个开启的 `backtrack` 函数）都包含一个 `duplicated` 。它记录的是在遍历中哪些元素已被选择过，作用是保证相等元素只被选择一次，以避免产生重复的搜索分支。 +- **重复选择剪枝**：整个搜索过程中只有一个 `selected` 。它记录的是当前状态中包含哪些元素，作用是避免某个元素在 `state` 中重复出现。 +- **相等元素剪枝**：每轮选择（即每个开启的 `backtrack` 函数）都包含一个 `duplicated` 。它记录的是在遍历中哪些元素已被选择过，作用是保证相等元素只被选择一次。 下图展示了两个剪枝条件的生效范围。注意，树中的每个节点代表一个选择，从根节点到叶节点的路径上的各个节点构成一个排列。 ![两种剪枝条件的作用范围](permutations_problem.assets/permutations_ii_pruning_summary.png) - -### 复杂度分析 - -假设元素两两之间互不相同，则 $n$ 个元素共有 $n!$ 种排列（阶乘）；在记录结果时，需要复制长度为 $n$ 的列表，使用 $O(n)$ 时间。因此，**时间复杂度为 $O(n!n)$** 。 - -最大递归深度为 $n$ ，使用 $O(n)$ 栈帧空间。`selected` 使用 $O(n)$ 空间。同一时刻最多共有 $n$ 个 `duplicated` ，使用 $O(n^2)$ 空间。因此，**全排列 I 的空间复杂度为 $O(n)$ ，全排列 II 的空间复杂度为 $O(n^2)$** 。 diff --git a/docs/chapter_backtracking/subset_sum_problem.md b/docs/chapter_backtracking/subset_sum_problem.md index 2ec9fcb38..30cf5ce17 100644 --- a/docs/chapter_backtracking/subset_sum_problem.md +++ b/docs/chapter_backtracking/subset_sum_problem.md @@ -6,13 +6,16 @@ 给定一个正整数数组 `nums` 和一个目标正整数 `target` ，请找出所有可能的组合，使得组合中的元素和等于 `target` 。给定数组无重复元素，每个元素可以被选取多次。请以列表形式返回这些组合，列表中不应包含重复组合。 -例如，输入集合 $\{3, 4, 5\}$ 和目标整数 $9$ ，由于集合中的数字可以被重复选取，因此解为 $\{3, 3, 3\}, \{4, 5\}$ 。请注意，子集是不区分元素顺序的，例如 $\{4, 5\}$ 和 $\{5, 4\}$ 是同一个子集。 +例如，输入集合 $\{3, 4, 5\}$ 和目标整数 $9$ ，解为 $\{3, 3, 3\}, \{4, 5\}$ 。需要注意两点： -### 从全排列引出解法 +- 输入集合中的元素可以被无限次重复选取。 +- 子集是不区分元素顺序的，比如 $\{4, 5\}$ 和 $\{5, 4\}$ 是同一个子集。 -类似于上节全排列问题的解法，我们可以把子集的生成过程想象成一系列选择的结果，并在选择过程中实时更新“元素和”，当元素和等于 `target` 时，就将子集记录至结果列表。 +### 参考全排列解法 -而与全排列问题不同的是，本题允许重复选取同一元素，因此无需借助 `selected` 布尔列表来记录元素是否已被选择。我们可以对全排列代码进行小幅修改，初步得到解题代码。 +类似于全排列问题，我们可以把子集的生成过程想象成一系列选择的结果，并在选择过程中实时更新“元素和”，当元素和等于 `target` 时，就将子集记录至结果列表。 + +而与全排列问题不同的是，**本题集合中的元素可以被无限次选取**，因此无需借助 `selected` 布尔列表来记录元素是否已被选择。我们可以对全排列代码进行小幅修改，初步得到解题代码。 === "Java" @@ -102,32 +105,42 @@ [class]{}-[func]{subsetSumINaive} ``` -向以上代码输入数组 $[3, 4, 5]$ 和目标元素 $9$ ，输出结果为 $[3, 3, 3], [4, 5], [5, 4]$ 。**虽然成功找出了所有和为 $9$ 的子集，但其中存在重复的子集 $[4, 5]$ 和 $[5, 4]$** 。这是因为搜索过程是区分选择顺序的，如下图所示，先选 $4$ 后选 $5$ 与先选 $5$ 后选 $4$ 是两种不同的情况。 +向以上代码输入数组 $[3, 4, 5]$ 和目标元素 $9$ ，输出结果为 $[3, 3, 3], [4, 5], [5, 4]$ 。**虽然成功找出了所有和为 $9$ 的子集，但其中存在重复的子集 $[4, 5]$ 和 $[5, 4]$** 。 -![子集搜索与越界剪枝](subset_sum_problem.assets/subset_sum_i_naive.png) +这是因为搜索过程是区分选择顺序的，然而子集不区分选择顺序。如下图所示，先选 $4$ 后选 $5$ 与先选 $5$ 后选 $4$ 是两个不同的分支，但两者对应同一个子集。 -### 重复子集剪枝 +![子集搜索与越界剪枝](subset_sum_problem.assets/subset_sum_i_naive.png) 为了去除重复子集，**一种直接的思路是对结果列表进行去重**。但这个方法效率很低，因为： - 当数组元素较多，尤其是当 `target` 较大时，搜索过程会产生大量的重复子集。 -- 比较子集（数组）的异同是很耗时的，需要先排序数组，再比较数组中每个元素的异同。 +- 比较子集（数组）的异同非常耗时，需要先排序数组，再比较数组中每个元素的异同。 + +### 重复子集剪枝 -为了达到最佳效率，**我们希望在搜索过程中通过剪枝进行去重**。观察下图，重复子集是在以不同顺序选择数组元素时产生的，具体来看： +**我们考虑在搜索过程中通过剪枝进行去重**。观察下图，重复子集是在以不同顺序选择数组元素时产生的，具体来看： 1. 第一轮和第二轮分别选择 $3$ , $4$ ，会生成包含这两个元素的所有子集，记为 $[3, 4, \cdots]$ 。 -2. 若第一轮选择 $4$ ，**则第二轮应该跳过 $3$** ，因为该选择产生的子集 $[4, 3, \cdots]$ 和 `1.` 中提到的子集完全重复。 -3. 同理，若第一轮选择 $5$ ，**则第二轮应该跳过 $3$ 和 $4$** ，因为子集 $[5, 3, \cdots]$ 和子集 $[5, 4, \cdots]$ 和之前的子集重复。 +2. 若第一轮选择 $4$ ，**则第二轮应该跳过 $3$** ，因为该选择产生的子集 $[4, 3, \cdots]$ 和 `1.` 中生成的子集完全重复。 + +分支越靠右，需要排除的分支也越多，例如： + +1. 前两轮选择 $3$ , $5$ ，生成子集 $[3, 5, \cdots]$ ； +2. 前两轮选择 $4$ , $5$ ，生成子集 $[4, 5, \cdots]$ ； +3. 若第一轮选择 $5$ ，**则第二轮应该跳过 $3$ 和 $4$** ，因为子集 $[5, 3, \cdots]$ 和子集 $[5, 4, \cdots]$ 和 `1.` , `2.` 中生成的子集完全重复。 ![不同选择顺序导致的重复子集](subset_sum_problem.assets/subset_sum_i_pruning.png) -总结来看，给定输入数组 $[x_1, x_2, \cdots, x_n]$ ，设搜索过程中的选择序列为 $[x_{i_1}, x_{i_2}, \cdots , x_{i_m}]$ ，则该选择序列需要满足 $i_1 \leq i_2 \leq \cdots \leq i_m$ 。**不满足该条件的选择序列都是重复子集**。 +总结来看，给定输入数组 $[x_1, x_2, \cdots, x_n]$ ，设搜索过程中的选择序列为 $[x_{i_1}, x_{i_2}, \cdots , x_{i_m}]$ ，则该选择序列需要满足 $i_1 \leq i_2 \leq \cdots \leq i_m$ ，**不满足该条件的选择序列都会造成重复，应当剪枝**。 ### 代码实现 -为实现该剪枝，我们初始化变量 `start` ，用于指示遍历起点。**当做出选择 $x_{i}$ 后，设定下一轮从索引 $i$ 开始遍历**，从而完成子集去重。 +为实现该剪枝，我们初始化变量 `start` ，用于指示遍历起点。**当做出选择 $x_{i}$ 后，设定下一轮从索引 $i$ 开始遍历**。这样做就可以让选择序列满足 $i_1 \leq i_2 \leq \cdots \leq i_m$ ，从而保证子集唯一。 -除此之外，我们还对代码进行了两项优化。首先，我们在开启搜索前将数组 `nums` 排序，在搜索过程中，**当子集和超过 `target` 时直接结束循环**，因为后边的元素更大，其子集和都一定会超过 `target` 。其次，**我们通过在 `target` 上执行减法来统计元素和**，当 `target` 等于 $0$ 时记录解，省去了元素和变量 `total` 。 +除此之外，我们还对代码进行了两项优化： + +- 在开启搜索前，先将数组 `nums` 排序。在遍历所有选择时，**当子集和超过 `target` 时直接结束循环**，因为后边的元素更大，其子集和都一定会超过 `target` 。 +- 省去元素和变量 `total`，**通过在 `target` 上执行减法来统计元素和**，当 `target` 等于 $0$ 时记录解。 === "Java" @@ -227,15 +240,17 @@ 给定一个正整数数组 `nums` 和一个目标正整数 `target` ，请找出所有可能的组合，使得组合中的元素和等于 `target` 。**给定数组可能包含重复元素，每个元素只可被选择一次**。请以列表形式返回这些组合，列表中不应包含重复组合。 -相比于上题，**本题的输入数组可能包含重复元素**，这引入了新的问题。例如，给定数组 $[4, \hat{4}, 5]$ 和目标元素 $9$ ，则现有代码的输出结果为 $[4, 5], [\hat{4}, 5]$ ，也出现了重复子集。**造成这种重复的原因是相等元素在某轮中被多次选择**。如下图所示，第一轮共有三个选择，其中两个都为 $4$ ，会产生两个重复的搜索分支，从而输出重复子集；同理，第二轮的两个 $4$ 也会产生重复子集。 +相比于上题，**本题的输入数组可能包含重复元素**，这引入了新的问题。例如，给定数组 $[4, \hat{4}, 5]$ 和目标元素 $9$ ，则现有代码的输出结果为 $[4, 5], [\hat{4}, 5]$ ，出现了重复子集。 + +**造成这种重复的原因是相等元素在某轮中被多次选择**。如下图所示，第一轮共有三个选择，其中两个都为 $4$ ，会产生两个重复的搜索分支，从而输出重复子集；同理，第二轮的两个 $4$ 也会产生重复子集。 ![相等元素导致的重复子集](subset_sum_problem.assets/subset_sum_ii_repeat.png) ### 相等元素剪枝 -为解决此问题，**我们需要限制相等元素在每一轮中只被选择一次**。实现方式比较巧妙：由于数组是已排序的，因此相等元素都是相邻的。利用该特性，在某轮选择中，若当前元素与其左边元素相等，则说明它已经被选择过，因此直接跳过当前元素。 +为解决此问题，**我们需要限制相等元素在每一轮中只被选择一次**。实现方式比较巧妙：由于数组是已排序的，因此相等元素都是相邻的。这意味着在某轮选择中，若当前元素与其左边元素相等，则说明它已经被选择过，因此直接跳过当前元素。 -与此同时，**本题规定数组元素只能被选择一次**。幸运的是，我们也可以利用变量 `start` 来满足该约束：当做出选择 $x_{i}$ 后，设定下一轮从索引 $i + 1$ 开始向后遍历。这样即能去除重复子集，也能避免重复选择相等元素。 +与此同时，**本题规定中的每个数组元素只能被选择一次**。幸运的是，我们也可以利用变量 `start` 来满足该约束：当做出选择 $x_{i}$ 后，设定下一轮从索引 $i + 1$ 开始向后遍历。这样即能去除重复子集，也能避免重复选择元素。 ### 代码实现 @@ -327,6 +342,6 @@ [class]{}-[func]{subsetSumII} ``` -下图展示了数组 $[4, 4, 5]$ 和目标元素 $9$ 的回溯过程，共包含四种剪枝操作。建议你将图示与代码注释相结合，理解整个搜索过程，以及每种剪枝操作是如何工作的。 +下图展示了数组 $[4, 4, 5]$ 和目标元素 $9$ 的回溯过程，共包含四种剪枝操作。请你将图示与代码注释相结合，理解整个搜索过程，以及每种剪枝操作是如何工作的。 ![子集和 II 回溯过程](subset_sum_problem.assets/subset_sum_ii.png) diff --git a/docs/chapter_divide_and_conquer/binary_search_recur.md b/docs/chapter_divide_and_conquer/binary_search_recur.md index 56340752a..d45a39e39 100644 --- a/docs/chapter_divide_and_conquer/binary_search_recur.md +++ b/docs/chapter_divide_and_conquer/binary_search_recur.md @@ -1,35 +1,44 @@ # 分治搜索策略 -我们已经学过，搜索算法分为两大类：暴力搜索、自适应搜索。暴力搜索的时间复杂度为 $O(n)$ 。自适应搜索利用特有的数据组织形式或先验信息，可达到 $O(\log n)$ 甚至 $O(1)$ 的时间复杂度。 +我们已经学过，搜索算法分为两大类： -### 基于分治的搜索算法 +- **暴力搜索**：它通过遍历数据结构实现，时间复杂度为 $O(n)$ 。 +- **自适应搜索**：它利用特有的数据组织形式或先验信息，可达到 $O(\log n)$ 甚至 $O(1)$ 的时间复杂度。 -实际上，**$O(\log n)$ 的搜索算法通常都是基于分治策略实现的**，例如： +实际上，**时间复杂度为 $O(\log n)$ 的搜索算法通常都是基于分治策略实现的**，例如： - 二分查找的每一步都将问题（在数组中搜索目标元素）分解为一个小问题（在数组的一半中搜索目标元素），这个过程一直持续到数组为空或找到目标元素为止。 - 树是分治关系的代表，在二叉搜索树、AVL 树、堆等数据结构中，各种操作的时间复杂度皆为 $O(\log n)$ 。 -分治之所以能够提升搜索效率，是因为暴力搜索每轮只能排除一个选项，**而基于分治的搜索每轮可以排除一半选项**。 - -### 基于分治实现二分 - -接下来，我们尝试从分治策略的角度分析二分查找的性质： +以二分查找为例： - **问题可以被分解**：二分查找递归地将原问题（在数组中进行查找）分解为子问题（在数组的一半中进行查找），这是通过比较中间元素和目标元素来实现的。 - **子问题是独立的**：在二分查找中，每轮只处理一个子问题，它不受另外子问题的影响。 - **子问题的解无需合并**：二分查找旨在查找一个特定元素，因此不需要将子问题的解进行合并。当子问题得到解决时，原问题也会同时得到解决。 -在之前章节中，我们基于递推（迭代）实现二分查找。现在，我们尝试基于递归分治来实现它。 +分治能够提升搜索效率，本质上是因为暴力搜索每轮只能排除一个选项，**而分治搜索每轮可以排除一半选项**。 + +### 基于分治实现二分 + +在之前的章节中，二分查找是基于递推（迭代）实现的。现在我们基于分治（递归）来实现它。 + +!!! question + + 给定一个长度为 $n$ 的有序数组 `nums` ，数组中所有元素都是唯一的，请查找元素 `target` 。 + +从分治角度，我们将搜索区间 $[i, j]$ 对应的子问题记为 $f(i, j)$ 。 -问题定义为：**在数组 `nums` 的区间 $[i, j]$ 内查找元素 `target`** ，记为 $f(i, j)$ 。 +从原问题 $f(0, n-1)$ 为起始点，二分查找的分治步骤为： -设数组长度为 $n$ ，则二分查找的流程为：从原问题 $f(0, n-1)$ 开始，每轮排除一半索引区间，递归求解规模减小一半的子问题，直至找到 `target` 或区间为空时返回。 +1. 计算搜索区间 $[i, j]$ 的中点 $m$ ，根据它排除一半搜索区间； +2. 递归求解规模减小一半的子问题，可能为 $f(i, m-1)$ 或 $f(m+1, j)$ ； +3. 循环第 `1.` , `2.` 步，直至找到 `target` 或区间为空时返回。 -下图展示了在数组中二分查找目标元素 $6$ 的分治过程。 +下图展示了在数组中二分查找元素 $6$ 的分治过程。 ![二分查找的分治过程](binary_search_recur.assets/binary_search_recur.png) -如下代码所示，我们声明一个递归函数 `dfs()` 来求解问题 $f(i, j)$ 。 +在实现代码中，我们声明一个递归函数 `dfs()` 来求解问题 $f(i, j)$ 。 === "Java" diff --git a/docs/chapter_divide_and_conquer/build_binary_tree_problem.md b/docs/chapter_divide_and_conquer/build_binary_tree_problem.md index 34486c69f..6044ae370 100644 --- a/docs/chapter_divide_and_conquer/build_binary_tree_problem.md +++ b/docs/chapter_divide_and_conquer/build_binary_tree_problem.md @@ -11,8 +11,8 @@ 原问题定义为从 `preorder` 和 `inorder` 构建二叉树。我们首先从分治的角度分析这道题： - **问题可以被分解**：从分治的角度切入，我们可以将原问题划分为两个子问题：构建左子树、构建右子树，加上一步操作：初始化根节点。而对于每个子树（子问题），我们仍然可以复用以上划分方法，将其划分为更小的子树（子问题），直至达到最小子问题（空子树）时终止。 -- **子问题是独立的**：左子树和右子树是相互独立的，它们之间没有交集。在构建左子树时，我们只需要关注中序遍历和前序遍历或后序遍历中与左子树对应的部分。右子树同理。 -- **子问题的解可以合并**：一旦我们得到了左子树和右子树，我们可以将它们链接到根节点上，从而得到原问题的解。 +- **子问题是独立的**：左子树和右子树是相互独立的，它们之间没有交集。在构建左子树时，我们只需要关注中序遍历和前序遍历中与左子树对应的部分。右子树同理。 +- **子问题的解可以合并**：一旦得到了左子树和右子树（子问题的解），我们就可以将它们链接到根节点上，得到原问题的解。 ### 如何划分子树 @@ -23,27 +23,27 @@ - 前序遍历：`[ 根节点 | 左子树 | 右子树 ]` ，例如上图 `[ 3 | 9 | 2 1 7 ]` ； - 中序遍历：`[ 左子树 | 根节点 ｜ 右子树 ]` ，例如上图 `[ 9 | 3 | 1 2 7 ]` ； -以上图数据为例，我们可以通过以下三步得到上述的划分结果： +以上图数据为例，我们可以通过以下步骤得到上述的划分结果： -1. 前序遍历的首元素 3 为根节点的值； -2. 查找根节点在 `inorder` 中的索引，基于该索引可将 `inorder` 划分为 `[ 9 | 3 ｜ 1 2 7 ]` ； -3. 根据 `inorder` 划分结果，可得左子树和右子树分别有 1 个和 3 个节点，从而可将 `preorder` 划分为 `[ 3 | 9 | 2 1 7 ]` ； +1. 前序遍历的首元素 3 是根节点的值； +2. 查找根节点 3 在 `inorder` 中的索引，利用该索引可将 `inorder` 划分为 `[ 9 | 3 ｜ 1 2 7 ]` ； +3. 根据 `inorder` 划分结果，易得左子树和右子树的节点数量分别为 1 和 3 ，从而可将 `preorder` 划分为 `[ 3 | 9 | 2 1 7 ]` ； ![在前序和中序遍历中划分子树](build_binary_tree_problem.assets/build_tree_preorder_inorder_division.png) -### 使用指针描述子树区间 +### 基于变量描述子树区间 -至此，**我们已经推导出根节点、左子树、右子树在 `preorder` 和 `inorder` 中的索引区间**。而为了描述这些索引区间，我们需要借助几个指针变量： +根据以上划分方法，**我们已经得到根节点、左子树、右子树在 `preorder` 和 `inorder` 中的索引区间**。而为了描述这些索引区间，我们需要借助几个指针变量： - 将当前树的根节点在 `preorder` 中的索引记为 $i$ ； - 将当前树的根节点在 `inorder` 中的索引记为 $m$ ； - 将当前树在 `inorder` 中的索引区间记为 $[l, r]$ ； -下表整理了根节点、左子树和右子树的索引区间在这些变量下的具体表示。 +如下表所示，通过以上变量即可表示根节点在 `preorder` 中的索引，以及子树在 `inorder` 中的索引区间。
-| | 子树根节点在 `preorder` 中的索引 | 子树在 `inorder` 中的索引区间 | +| | 根节点在 `preorder` 中的索引 | 子树在 `inorder` 中的索引区间 | | ------ | -------------------------------- | ----------------------------- | | 当前树 | $i$ | $[l, r]$ | | 左子树 | $i + 1$ | $[l, m-1]$ | @@ -57,7 +57,7 @@ ### 代码实现 -接下来就可以实现代码了。为了提升查询 $m$ 的效率，我们借助一个哈希表 `hmap` 来存储 `inorder` 列表元素到索引的映射。 +为了提升查询 $m$ 的效率，我们借助一个哈希表 `hmap` 来存储数组 `inorder` 中元素到索引的映射。 === "Java" @@ -147,7 +147,7 @@ [class]{}-[func]{buildTree} ``` -下图展示了构建二叉树的递归过程，各个节点是在向下“递”的过程中建立的，而各条边是在向上“归”的过程中建立的。 +下图展示了构建二叉树的递归过程，各个节点是在向下“递”的过程中建立的，而各条边（即引用）是在向上“归”的过程中建立的。 === "<1>" ![构建二叉树的递归过程](build_binary_tree_problem.assets/built_tree_step1.png) diff --git a/docs/chapter_divide_and_conquer/divide_and_conquer.md b/docs/chapter_divide_and_conquer/divide_and_conquer.md index c6e9e8f1d..28795b4b5 100644 --- a/docs/chapter_divide_and_conquer/divide_and_conquer.md +++ b/docs/chapter_divide_and_conquer/divide_and_conquer.md @@ -1,14 +1,14 @@ # 分治算法 -「分治 Divide and Conquer」，全称分而治之，是一种非常重要的算法策略。分治通常基于递归实现，包括“分”和“治”两部分，主要步骤如下： +「分治 Divide and Conquer」，全称分而治之，是一种非常重要且常见的算法策略。分治通常基于递归实现，包括“分”和“治”两步： 1. **分（划分阶段）**：递归地将原问题分解为两个或多个子问题，直至到达最小子问题时终止； 2. **治（合并阶段）**：从已知解的最小子问题开始，从底至顶地将子问题的解进行合并，从而构建出原问题的解； -之前学过的「归并排序」是分治策略的典型应用之一，对于该算法： +已介绍过的「归并排序」是分治策略的典型应用之一，它的分治策略为： 1. **分**：递归地将原数组（原问题）划分为两个子数组（子问题），直到子数组只剩一个元素（最小子问题）。 -2. **治**：从底至顶地将有序的子数组进行合并，从而得到有序的原数组。 +2. **治**：从底至顶地将有序的子数组（子问题的解）进行合并，从而得到有序的原数组（原问题的解）。 ![归并排序的分治策略](divide_and_conquer.assets/divide_and_conquer_merge_sort.png) @@ -18,26 +18,26 @@ 1. **问题可以被分解**：原问题可以被分解成规模更小、类似的子问题，以及能够以相同方式递归地进行划分。 2. **子问题是独立的**：子问题之间是没有重叠的，互相没有依赖，可以被独立解决。 -3. **子问题的解可以被合并**：原问题的解可以通过合并子问题的解得来。 +3. **子问题的解可以被合并**：原问题的解通过合并子问题的解得来。 -归并排序显然是满足以上三条判断依据的： +显然归并排序，满足以上三条判断依据： -1. 递归地将数组（原问题）划分为两个子数组（子问题），当子数组只有一个元素时天然有序； -2. 每个子数组都可以独立地进行排序，因此子问题是独立的； +1. 递归地将数组（原问题）划分为两个子数组（子问题）； +2. 每个子数组都可以独立地进行排序（子问题可以独立进行求解）； 3. 两个有序子数组（子问题的解）可以被合并为一个有序数组（原问题的解）； ## 通过分治提升效率 -分治不仅可以有效地解决算法问题，**往往还可以提升算法效率**。在排序算法中，归并排序相较于选择、冒泡、插入排序更快，就是因为其应用了分治策略。 +分治不仅可以有效地解决算法问题，**往往还可以带来算法效率的提升**。在排序算法中，快速排序、归并排序、堆排序相较于选择、冒泡、插入排序更快，就是因为它们应用了分治策略。 -那么，我们不禁发问：**为什么分治可以提升算法效率，其底层逻辑是什么**？换句话说，将大问题分解为多个子问题、解决子问题、将子问题的解合并为原问题的解，这三步为什么比直接解决原问题效率更高？这个问题可以从操作数量和并行计算两方面来讨论。 +那么，我们不禁发问：**为什么分治可以提升算法效率，其底层逻辑是什么**？换句话说，将大问题分解为多个子问题、解决子问题、将子问题的解合并为原问题的解，这几步的效率为什么比直接解决原问题的效率更高？这个问题可以从操作数量和并行计算两方面来讨论。 ### 操作数量优化 -以「冒泡排序」为例，其处理一个长度为 $n$ 的数组需要 $O(n^2)$ 时间。假设我们把数组从中点分为两个子数组，则划分需要 $O(n)$ 时间，排序每个子数组需要 $O((n/2)^2)$ 时间，合并两个子数组需要 $O(n)$ 时间，总体时间复杂度为： +以「冒泡排序」为例，其处理一个长度为 $n$ 的数组需要 $O(n^2)$ 时间。假设我们把数组从中点分为两个子数组，则划分需要 $O(n)$ 时间，排序每个子数组需要 $O((\frac{n}{2})^2)$ 时间，合并两个子数组需要 $O(n)$ 时间，总体时间复杂度为： $$ -O(n + (n/2)^2 \times 2 + n) = O(n^2 / 2 + 2n) +O(n + (\frac{n}{2})^2 \times 2 + n) = O(\frac{n^2}{2} + 2n) $$ ![划分数组前后的冒泡排序](divide_and_conquer.assets/divide_and_conquer_bubble_sort.png) @@ -52,11 +52,11 @@ n(n - 4) & > 0 \end{aligned} $$ -**这意味着当 $n > 4$ 时，划分后的操作数量更少，排序效率可能更高**。当然，划分后的时间复杂度仍然是平方阶 $O(n^2)$ ，即复杂度并没有降低，只是其中的常数项变小了。 +**这意味着当 $n > 4$ 时，划分后的操作数量更少，排序效率应该更高**。请注意，划分后的时间复杂度仍然是平方阶 $O(n^2)$ ，只是复杂度中的常数项变小了。 -那么，**如果我们把子数组不断地再从中点划分为两个子数组**，直至子数组只剩一个元素时停止划分呢？这就达到了「归并排序」的情况，时间复杂度为 $O(n \log n)$ 。 +进一步想，**如果我们把子数组不断地再从中点划分为两个子数组**，直至子数组只剩一个元素时停止划分呢？这种思路实际上就是「归并排序」，时间复杂度为 $O(n \log n)$ 。 -再思考，**如果我们多设置几个划分点**，将原数组平均划分为 $k$ 个子数组呢？这种情况就与「桶排序」非常类似了，它非常适合排序海量数据，理论上时间复杂度可以达到 $O(n + k)$ 。 +再思考，**如果我们多设置几个划分点**，将原数组平均划分为 $k$ 个子数组呢？这种情况与「桶排序」非常类似，它非常适合排序海量数据，理论上时间复杂度可以达到 $O(n + k)$ 。 ### 并行计算优化 @@ -64,7 +64,7 @@ $$ 并行优化在多核或多处理器的环境中尤其有效，因为系统可以同时处理多个子问题，更加充分地利用计算资源，从而显著减少总体的运行时间。 -例如在桶排序中，我们将海量的数据平均分配到各个桶中，则可所有桶的排序任务分散到各个计算单元，完成后再进行结果合并。 +比如在桶排序中，我们将海量的数据平均分配到各个桶中，则可所有桶的排序任务分散到各个计算单元，完成后再进行结果合并。 ![桶排序的并行计算](divide_and_conquer.assets/divide_and_conquer_parallel_computing.png) @@ -78,7 +78,7 @@ $$ - **汉诺塔问题**：汉诺塔问题可以视为典型的分治策略，通过递归解决。 - **求解逆序对**：在一个序列中，如果前面的数字大于后面的数字，那么这两个数字构成一个逆序对。求解逆序对问题可以通过分治的思想，借助归并排序进行求解。 -另一方面，**分治在算法和数据结构的设计中应用非常广泛**，举几个已经学过的例子： +另一方面，分治在算法和数据结构的设计中应用非常广泛，举几个已经学过的例子： - **二分查找**：二分查找是将有序数组从中点索引分为两部分，然后根据目标值与中间元素值比较结果，决定排除哪一半区间，然后在剩余区间执行相同的二分操作。 - **归并排序**：文章开头已介绍，不再赘述。 diff --git a/docs/chapter_divide_and_conquer/hanota_problem.md b/docs/chapter_divide_and_conquer/hanota_problem.md index 8b10cabb4..ec3f50a68 100644 --- a/docs/chapter_divide_and_conquer/hanota_problem.md +++ b/docs/chapter_divide_and_conquer/hanota_problem.md @@ -1,6 +1,6 @@ # 汉诺塔问题 -在归并排序和构建二叉树中，我们将原问题分解为两个规模为原问题一半的子问题。然而，对于即将介绍的汉诺塔问题，我们采用不同的分解策略。 +在归并排序和构建二叉树中，我们都是将原问题分解为两个规模为原问题一半的子问题。然而对于汉诺塔问题，我们采用不同的分解策略。 !!! question @@ -12,7 +12,7 @@ ![汉诺塔问题示例](hanota_problem.assets/hanota_example.png) -在本文中，**我们将规模为 $i$ 的汉诺塔问题记做 $f(i)$** 。例如 $f(3)$ 代表将 $3$ 个圆盘从 `A` 移动至 `C` 的汉诺塔问题。 +**我们将规模为 $i$ 的汉诺塔问题记做 $f(i)$** 。例如 $f(3)$ 代表将 $3$ 个圆盘从 `A` 移动至 `C` 的汉诺塔问题。 ### 考虑基本情况 @@ -30,7 +30,7 @@ 2. 再将大圆盘从 `A` 移至 `C` ； 3. 最后将小圆盘从 `B` 移至 `C` ； -如下图所示，对于小圆盘的移动，**我们称 `C` 为目标柱、`B` 为缓冲柱**。 +解决问题 $f(2)$ 的过程可总结为：**将两个圆盘借助 `B` 从 `A` 移至 `C`** 。其中，`C` 称为目标柱、`B` 称为缓冲柱。 === "<1>" ![规模为 2 问题的解](hanota_problem.assets/hanota_f2_step1.png) @@ -46,10 +46,10 @@ ### 子问题分解 -对于问题 $f(3)$ ，即当有三个圆盘时，情况变得稍微复杂了一些。由于已知 $f(1)$ 和 $f(2)$ 的解，我们可以从分治角度思考，**将 `A` 顶部的两个圆盘看做一个整体**，并执行以下步骤： +对于问题 $f(3)$ ，即当有三个圆盘时，情况变得稍微复杂了一些。由于已知 $f(1)$ 和 $f(2)$ 的解，因此可从分治角度思考，**将 `A` 顶部的两个圆盘看做一个整体**，执行以下步骤： 1. 令 `B` 为目标柱、`C` 为缓冲柱，将两个圆盘从 `A` 移动至 `B` ； -2. 将 `A` 中剩余的一个圆盘从 `A` 移动至 `C` ； +2. 将 `A` 中剩余的一个圆盘从 `A` 直接移动至 `C` ； 3. 令 `C` 为目标柱、`A` 为缓冲柱，将两个圆盘从 `B` 移动至 `C` ； 这样三个圆盘就被顺利地从 `A` 移动至 `C` 了。 @@ -66,21 +66,21 @@ === "<4>" ![hanota_f3_step4](hanota_problem.assets/hanota_f3_step4.png) -本质上看，我们将问题 $f(3)$ 划分为两个子问题 $f(2)$ 和子问题 $f(1)$。按顺序解决这三个子问题之后，原问题随之得到解决。**以上分析说明了子问题的独立性，以及解是可以合并的**。 +本质上看，**我们将问题 $f(3)$ 划分为两个子问题 $f(2)$ 和子问题 $f(1)$** 。按顺序解决这三个子问题之后，原问题随之得到解决。这说明子问题是独立的，且解是可以合并的。 -至此，我们可总结出汉诺塔问题的分治策略：**将原问题 $f(n)$ 划分为两个子问题 $f(n-1)$ 和一个子问题 $f(1)$** 。子问题的解决顺序为： +至此，我们可总结出汉诺塔问题的分治策略：将原问题 $f(n)$ 划分为两个子问题 $f(n-1)$ 和一个子问题 $f(1)$ 。子问题的解决顺序为： 1. 将 $n-1$ 个圆盘借助 `C` 从 `A` 移至 `B` ； 2. 将剩余 $1$ 个圆盘从 `A` 直接移至 `C` ； 3. 将 $n-1$ 个圆盘借助 `A` 从 `B` 移至 `C` ； -并且，对于这两个子问题 $f(n-1)$ ，**可以通过相同的方式进行递归划分**，直至达到最小子问题 $f(1)$ 。而 $f(1)$ 的解是已知的，只需一次移动操作即可。 +对于这两个子问题 $f(n-1)$ ，**可以通过相同的方式进行递归划分**，直至达到最小子问题 $f(1)$ 。而 $f(1)$ 的解是已知的，只需一次移动操作即可。 ![汉诺塔问题的分治策略](hanota_problem.assets/hanota_divide_and_conquer.png) ### 代码实现 -在代码实现中，我们声明一个递归函数 `dfs(i, src, buf, tar)` ，它的作用是将柱 `src` 顶部的 $i$ 个圆盘借助缓冲柱 `buf` 移动至目标柱 `tar` 。 +在代码中，我们声明一个递归函数 `dfs(i, src, buf, tar)` ，它的作用是将柱 `src` 顶部的 $i$ 个圆盘借助缓冲柱 `buf` 移动至目标柱 `tar` 。 === "Java" diff --git a/docs/chapter_hashing/hash_algorithm.md b/docs/chapter_hashing/hash_algorithm.md index 0273e99d2..f2bbcc4b1 100644 --- a/docs/chapter_hashing/hash_algorithm.md +++ b/docs/chapter_hashing/hash_algorithm.md @@ -1,28 +1,30 @@ # 哈希算法 -在上两节中，我们了解了哈希表的工作原理，以及哈希冲突的处理方法。然而，无论是开放寻址还是链地址法，**它们只能保证哈希表可以在发生冲突时正常工作，但无法减少哈希冲突的发生**。 +在上两节中，我们了解了哈希表的工作原理和哈希冲突的处理方法。然而无论是开放寻址还是链地址法，**它们只能保证哈希表可以在发生冲突时正常工作，但无法减少哈希冲突的发生**。 -如果哈希冲突过于频繁，哈希表的性能则会急剧劣化。例如对于链地址哈希表，理想情况下键值对平均分布在各个桶中，达到最好的查询效率；最差情况下全部键值都被存储到同一个桶中，时间复杂度退化至 $O(n)$ 。 +如果哈希冲突过于频繁，哈希表的性能则会急剧劣化。对于链地址哈希表，理想情况下键值对平均分布在各个桶中，达到最佳查询效率；最差情况下所有键值对都被存储到同一个桶中，时间复杂度退化至 $O(n)$ 。 ![哈希冲突的最佳与最差情况](hash_algorithm.assets/hash_collision_best_worst_condition.png) -**键值对的分布情况是由哈希函数决定的**。回忆哈希函数的计算步骤，先计算哈希值，再对数组长度取模： +**键值对的分布情况由哈希函数决定**。回忆哈希函数的计算步骤，先计算哈希值，再对数组长度取模： ```shell index = hash(key) % capacity ``` -观察以上公式，当哈希表容量 `capacity` 固定时，**哈希算法 `hash()` 决定了输出值**，进而决定了键值对在哈希表中的分布。因此，为了减小哈希冲突的发生概率，我们需要将注意力集中在哈希算法 `hash()` 的设计上。 +观察以上公式，当哈希表容量 `capacity` 固定时，**哈希算法 `hash()` 决定了输出值**，进而决定了键值对在哈希表中的分布情况。 + +这意味着，为了减小哈希冲突的发生概率，我们应当将注意力集中在哈希算法 `hash()` 的设计上。 ## 哈希算法的目标 -为了在编程语言中实现“既快又稳”的哈希表数据结构，哈希算法应包含以下特点： +为了实现“既快又稳”的哈希表数据结构，哈希算法应包含以下特点： - **确定性**：对于相同的输入，哈希算法应始终产生相同的输出。这样才能确保哈希表是可靠的。 - **效率高**：计算哈希值的过程应该足够快。计算开销越小，哈希表的实用性越高。 - **均匀分布**：哈希算法应使得键值对平均分布在哈希表中。分布越平均，哈希冲突的概率就越低。 -实际上，哈希算法除了可以用于实现哈希表，还广泛应用于其他领域中，包括： +实际上，哈希算法除了可以用于实现哈希表，还广泛应用于其他领域中。举两个例子： - **密码存储**：为了保护用户密码的安全，系统通常不会直接存储用户的明文密码，而是存储密码的哈希值。当用户输入密码时，系统会对输入的密码计算哈希值，然后与存储的哈希值进行比较。如果两者匹配，那么密码就被视为正确。 - **数据完整性检查**：数据发送方可以计算数据的哈希值并将其一同发送；接收方可以重新计算接收到的数据的哈希值，并与接收到的哈希值进行比较。如果两者匹配，那么数据就被视为完整的。 @@ -32,11 +34,11 @@ index = hash(key) % capacity - **抗碰撞性**：应当极其困难找到两个不同的输入，使得它们的哈希值相同。 - **雪崩效应**：输入的微小变化应当导致输出的显著且不可预测的变化。 -注意，**“均匀分布”与“抗碰撞性”是两个独立的概念**，满足均匀分布不一定满足抗碰撞性。例如，在随机输入 `key` 下，哈希函数 `key % 100` 可以产生均匀分布的输出。然而，该哈希算法过于简单，所有后两位相等的 `key` 的输出都相同，因此我们可以很容易地从哈希值反推出可用的 `key` ，从而破解密码。 +请注意，**“均匀分布”与“抗碰撞性”是两个独立的概念**，满足均匀分布不一定满足抗碰撞性。例如，在随机输入 `key` 下，哈希函数 `key % 100` 可以产生均匀分布的输出。然而该哈希算法过于简单，所有后两位相等的 `key` 的输出都相同，因此我们可以很容易地从哈希值反推出可用的 `key` ，从而破解密码。 ## 哈希算法的设计 -哈希算法的设计是一个复杂且需要考虑许多因素的问题。然而，对于一些简单场景，我们也能设计一些简单的哈希算法，以字符串哈希为例： +哈希算法的设计是一个复杂且需要考虑许多因素的问题。然而对于简单场景，我们也能设计一些简单的哈希算法。以字符串哈希为例： - **加法哈希**：对输入的每个字符的 ASCII 码进行相加，将得到的总和作为哈希值。 - **乘法哈希**：利用了乘法的不相关性，每轮乘以一个常数，将各个字符的 ASCII 码累积到哈希值中。 @@ -175,7 +177,7 @@ index = hash(key) % capacity [class]{}-[func]{rot_hash} ``` -观察发现，每种哈希算法的最后一步都是对大质数 $1000000007$ 取模，以确保哈希值在合适的范围内。值得思考的是，为什么要强调对质数取模，对合数取模的弊端是什么？这是一个有趣的问题。 +观察发现，每种哈希算法的最后一步都是对大质数 $1000000007$ 取模，以确保哈希值在合适的范围内。值得思考的是，为什么要强调对质数取模，或者说对合数取模的弊端是什么？这是一个有趣的问题。 先抛出结论：**当我们使用大质数作为模数时，可以最大化地保证哈希值的均匀分布**。因为质数不会与其他数字存在公约数，可以减少因取模操作而产生的周期性模式，从而避免哈希冲突。 @@ -199,17 +201,21 @@ $$ \end{aligned} $$ -值得强调的是，如果能够保证 `key` 是随机均匀分布的，那么选择质数或者合数作为模数都是可以的，它们都能输出均匀分布的哈希值。而当 `key` 的分布存在某种周期性时，对合数取模更容易出现聚集现象。 +值得说明的是，如果能够保证 `key` 是随机均匀分布的，那么选择质数或者合数作为模数都是可以的，它们都能输出均匀分布的哈希值。而当 `key` 的分布存在某种周期性时，对合数取模更容易出现聚集现象。 -总而言之，我们通常选取质数作为模数，并且这个质数最好大一些，以提升哈希算法的稳健性。 +总而言之，我们通常选取质数作为模数，并且这个质数最好足够大，以尽可能消除周期性模式，提升哈希算法的稳健性。 ## 常见哈希算法 不难发现，以上介绍的简单哈希算法都比较“脆弱”，远远没有达到哈希算法的设计目标。例如，由于加法和异或满足交换律，因此加法哈希和异或哈希无法区分内容相同但顺序不同的字符串，这可能会加剧哈希冲突，并引起一些安全问题。 -在实际中，我们通常会用一些标准哈希算法，例如 MD5, SHA-1, SHA-2, SHA3 等。它们可以将任意长度的输入数据映射到恒定长度的哈希值。近一个世纪以来，哈希算法处在不断升级与优化的过程中。一部分研究人员努力提升哈希算法的性能，另一部分研究人员和黑客则致力于寻找哈希算法的安全性问题。 +在实际中，我们通常会用一些标准哈希算法，例如 MD5 , SHA-1 , SHA-2 , SHA3 等。它们可以将任意长度的输入数据映射到恒定长度的哈希值。 + +近一个世纪以来，哈希算法处在不断升级与优化的过程中。一部分研究人员努力提升哈希算法的性能，另一部分研究人员和黑客则致力于寻找哈希算法的安全性问题。直至目前： -直至目前，MD5 和 SHA-1 已多次被成功攻击，因此它们被各类安全应用弃用。SHA-2 系列中的 SHA-256 是最安全的哈希算法之一，仍未出现成功的攻击案例，因此常被用在各类安全应用与协议中。SHA-3 相较 SHA-2 的实现开销更低、计算效率更高，但目前使用覆盖度不如 SHA-2 系列。 +- MD5 和 SHA-1 已多次被成功攻击，因此它们被各类安全应用弃用。 +- SHA-2 系列中的 SHA-256 是最安全的哈希算法之一，仍未出现成功的攻击案例，因此常被用在各类安全应用与协议中。 +- SHA-3 相较 SHA-2 的实现开销更低、计算效率更高，但目前使用覆盖度不如 SHA-2 系列。 | | MD5 | SHA-1 | SHA-2 | SHA-3 | | -------- | ------------------------------ | ---------------- | ---------------------------- | -------------------- | @@ -425,10 +431,8 @@ $$ // 节点对象 Instance of 'ListNode' 的哈希值为 1033450432 ``` -在大多数编程语言中，**只有不可变对象才可作为哈希表的 `key`** 。假如我们将列表（动态数组）作为 `key` ，当列表的内容发生变化时，它的哈希值也随之改变，我们就无法在哈希表中查询到原先的 `value` 了。 - -虽然自定义对象（例如链表节点）的成员变量是可变的，但它是可哈希的，这是因为对象的哈希值默认基于内存地址生成。即使对象的内容发生了变化，但它的内存地址不变，哈希值仍然是不变的。 +在许多编程语言中，**只有不可变对象才可作为哈希表的 `key`** 。假如我们将列表（动态数组）作为 `key` ，当列表的内容发生变化时，它的哈希值也随之改变，我们就无法在哈希表中查询到原先的 `value` 了。 -!!! tip "向哈希函数加盐" +虽然自定义对象（比如链表节点）的成员变量是可变的，但它是可哈希的。**这是因为对象的哈希值通常是基于内存地址生成的**，即使对象的内容发生了变化，但它的内存地址不变，哈希值仍然是不变的。 - Python 解释器在每次启动时，都会为字符串哈希函数加入一个随机的盐（Salt）值。因此在不同的 Python 运行实例中，同一字符串的哈希值通常是不同的。此做法可以有效防止 HashDoS 攻击，提升哈希算法的安全性。 +细心的你可能发现在不同控制台中运行程序时，输出的哈希值是不同的。**这是因为 Python 解释器在每次启动时，都会为字符串哈希函数加入一个随机的盐（Salt）值**。这种做法可以有效防止 HashDoS 攻击，提升哈希算法的安全性。 diff --git a/docs/chapter_hashing/hash_collision.md b/docs/chapter_hashing/hash_collision.md index 3388628d8..c82c5331c 100644 --- a/docs/chapter_hashing/hash_collision.md +++ b/docs/chapter_hashing/hash_collision.md @@ -1,11 +1,11 @@ # 哈希冲突 -上节提到，**通常情况下哈希函数的输入空间远大于输出空间**，因此哈希冲突是不可避免的。例如，输入空间为全体整数，输出空间为数组容量大小，则必然有多个整数映射至同一数组索引。 +上节提到，**通常情况下哈希函数的输入空间远大于输出空间**，因此理论上哈希冲突是不可避免的。比如，输入空间为全体整数，输出空间为数组容量大小，则必然有多个整数映射至同一数组索引。 -哈希冲突会导致查询结果错误，严重影响哈希表的可用性。为解决该问题，我们可以每当遇到哈希冲突时就进行哈希表扩容，直至冲突消失为止。此方法简单粗暴且有效，但效率太低，因为哈希表扩容需要进行大量的数据搬运与哈希值计算。为了提升效率，我们换一种思路： +哈希冲突会导致查询结果错误，严重影响哈希表的可用性。为解决该问题，我们可以每当遇到哈希冲突时就进行哈希表扩容，直至冲突消失为止。此方法简单粗暴且有效，但效率太低，因为哈希表扩容需要进行大量的数据搬运与哈希值计算。为了提升效率，我们切换一下思路： 1. 改良哈希表数据结构，**使得哈希表可以在存在哈希冲突时正常工作**。 -2. 仅在必要时，即当哈希冲突比较严重时，执行扩容操作。 +2. 仅在必要时，即当哈希冲突比较严重时，才执行扩容操作。 哈希表的结构改良方法主要包括链式地址和开放寻址。 @@ -23,12 +23,12 @@ 该方法存在一些局限性，包括： -- **占用空间增大**，由于链表或二叉树包含节点指针，相比数组更加耗费内存空间； -- **查询效率降低**，因为需要线性遍历链表来查找对应元素； +- **占用空间增大**，链表包含节点指针，它相比数组更加耗费内存空间。 +- **查询效率降低**，因为需要线性遍历链表来查找对应元素。 以下给出了链式地址哈希表的简单实现，需要注意： -- 为了使得代码尽量简短，我们使用列表（动态数组）代替链表。换句话说，哈希表（数组）包含多个桶，每个桶都是一个列表。 +- 为了使得代码尽量简短，我们使用列表（动态数组）代替链表。在这种设定下，哈希表（数组）包含多个桶，每个桶都是一个列表。 - 以下代码实现了哈希表扩容方法。具体来看，当负载因子超过 $0.75$ 时，我们将哈希表扩容至 $2$ 倍。 === "Java" @@ -99,30 +99,29 @@ !!! tip - 为了提高效率，**我们可以将链表转换为「AVL 树」或「红黑树」**，从而将查询操作的时间复杂度优化至 $O(\log n)$ 。 + 当链表很长时，查询效率 $O(n)$ 很差，**此时可以将链表转换为「AVL 树」或「红黑树」**，从而将查询操作的时间复杂度优化至 $O(\log n)$ 。 ## 开放寻址 -「开放寻址 Open Addressing」不引入额外的数据结构，而是通过“多次探测”来处理哈希冲突，探测方式主要包括线性探测、平方探测、多次哈希。 +「开放寻址 Open Addressing」不引入额外的数据结构，而是通过“多次探测”来处理哈希冲突，探测方式主要包括线性探测、平方探测、多次哈希等。 ### 线性探测 线性探测采用固定步长的线性查找来进行探测，对应的哈希表操作方法为： - **插入元素**：通过哈希函数计算数组索引，若发现桶内已有元素，则从冲突位置向后线性遍历（步长通常为 $1$ ），直至找到空位，将元素插入其中。 -- **查找元素**：若发现哈希冲突，则使用相同步长向后线性遍历，直到找到对应元素，返回 `value` 即可；或者若遇到空位，说明目标键值对不在哈希表中，返回 $\text{None}$ 。 +- **查找元素**：若发现哈希冲突，则使用相同步长向后线性遍历，直到找到对应元素，返回 `value` 即可；如果遇到空位，说明目标键值对不在哈希表中，返回 $\text{None}$ 。 ![线性探测](hash_collision.assets/hash_table_linear_probing.png) 然而，线性探测存在以下缺陷： -- **不能直接删除元素**。删除元素会在数组内产生一个空位，查找其他元素时，该空位可能导致程序误判元素不存在。因此，需要借助一个标志位来标记已删除元素。 -- **容易产生聚集**。数组内连续被占用位置越长，这些连续位置发生哈希冲突的可能性越大，进一步促使这一位置的“聚堆生长”，最终导致增删查改操作效率降低。 +- **不能直接删除元素**。删除元素会在数组内产生一个空位，当查找该空位之后的元素时，该空位可能导致程序误判元素不存在。为此，通常需要借助一个标志位来标记已删除元素。 +- **容易产生聚集**。数组内连续被占用位置越长，这些连续位置发生哈希冲突的可能性越大，进一步促使这一位置的聚堆生长，形成恶性循环，最终导致增删查改操作效率劣化。 -如以下代码所示，为开放寻址（线性探测）哈希表的简单实现，重点包括： +以下代码实现了一个简单的开放寻址（线性探测）哈希表。值得注意两点： -- 我们使用一个固定的键值对实例 `removed` 来标记已删除元素。也就是说，当一个桶为 $\text{None}$ 或 `removed` 时，这个桶都是空的，可用于放置键值对。 -- 被标记为已删除的空间是可以再次被使用的。当插入元素时，若通过哈希函数找到了被标记为已删除的索引，则可将该元素放置到该索引。 +- 我们使用一个固定的键值对实例 `removed` 来标记已删除元素。也就是说，当一个桶内的元素为 $\text{None}$ 或 `removed` 时，说明这个桶是空的，可用于放置键值对。 - 在线性探测时，我们从当前索引 `index` 向后遍历；而当越过数组尾部时，需要回到头部继续遍历。 === "Java" @@ -200,10 +199,10 @@ 与线性探测相比，多次哈希方法不易产生聚集，但多个哈希函数会增加额外的计算量。 -!!! 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 29be12d1b..d69a707b5 100755 --- a/docs/chapter_hashing/hash_map.md +++ b/docs/chapter_hashing/hash_map.md @@ -9,7 +9,7 @@ 除哈希表外，我们还可以使用数组或链表实现查询功能。若将学生数据看作数组（链表）元素，则有： - **添加元素**：仅需将元素添加至数组（链表）的尾部即可，使用 $O(1)$ 时间； -- **查询元素**：由于数组（链表）是乱序的，因此需要遍历数组（链表）中的所有元素，使用 $O(n)$ 时间； +- **查询元素**：由于数组（链表）是乱序的，因此需要遍历其中的所有元素，使用 $O(n)$ 时间； - **删除元素**：需要先查询到元素，再从数组中删除，使用 $O(n)$ 时间；
@@ -22,7 +22,7 @@
-观察发现，**在哈希表中进行增删查改的时间复杂度都是 $O(1)$** ，非常高效。因此，哈希表常用于对查找效率要求较高的场景。 +观察发现，**在哈希表中进行增删查改的时间复杂度都是 $O(1)$** ，非常高效。 ## 哈希表常用操作 @@ -434,7 +434,10 @@ 那么，如何基于 `key` 来定位对应的桶呢？这是通过「哈希函数 Hash Function」实现的。哈希函数的作用是将一个较大的输入空间映射到一个较小的输出空间。在哈希表中，输入空间是所有 `key` ，输出空间是所有桶（数组索引）。换句话说，输入一个 `key` ，**我们可以通过哈希函数得到该 `key` 对应的键值对在数组中的存储位置**。 -输入一个 `key` ，哈希函数的计算过程分为两步：首先，通过哈希算法 `hash()` 计算得到哈希值；接下来，将哈希值对桶数量（数组长度）`capacity` 取模，从而获取该 `key` 对应的数组索引 `index` 。 +输入一个 `key` ，哈希函数的计算过程分为两步： + +1. 通过某种哈希算法 `hash()` 计算得到哈希值； +2. 将哈希值对桶数量（数组长度）`capacity` 取模，从而获取该 `key` 对应的数组索引 `index` ； ```shell index = hash(key) % capacity @@ -446,7 +449,7 @@ index = hash(key) % capacity ![哈希函数工作原理](hash_map.assets/hash_function.png) -以下代码给出了一个简单哈希表实现。其中，我们将 `key` 和 `value` 封装成一个类 `Pair` ，以表示键值对。 +以下代码实现了一个简单哈希表。其中，我们将 `key` 和 `value` 封装成一个类 `Pair` ，以表示键值对。 === "Java" @@ -547,7 +550,7 @@ index = hash(key) % capacity ## 哈希冲突与扩容 -本质上看，哈希函数的作用是将输入空间（`key` 范围）映射到输出空间（数组索引范围），而输入空间往往远大于输出空间。因此，**理论上一定存在“多个输入对应相同输出”的情况**。 +本质上看，哈希函数的作用是将所有 `key` 构成的输入空间映射到数组所有索引构成的输出空间，而输入空间往往远大于输出空间。因此，**理论上一定存在“多个输入对应相同输出”的情况**。 对于上述示例中的哈希函数，当输入的 `key` 后两位相同时，哈希函数的输出结果也相同。例如，查询学号为 12836 和 20336 的两个学生时，我们得到： @@ -564,6 +567,6 @@ index = hash(key) % capacity ![哈希表扩容](hash_map.assets/hash_table_reshash.png) -类似于数组扩容，哈希表扩容需将所有键值对从原哈希表迁移至新哈希表，非常耗时。并且由于哈希表容量 `capacity` 改变，我们需要重新计算所有键值对的存储位置，进一步提高了扩容过程的计算开销。因此，编程语言通常会预留足够大的哈希表容量，防止频繁扩容。 +类似于数组扩容，哈希表扩容需将所有键值对从原哈希表迁移至新哈希表，非常耗时。并且由于哈希表容量 `capacity` 改变，我们需要通过哈希函数来重新计算所有键值对的存储位置，这进一步提高了扩容过程的计算开销。为此，编程语言通常会预留足够大的哈希表容量，防止频繁扩容。 -在哈希表中，「负载因子 Load Factor」是一个重要概念，其定义为哈希表的元素数量除以桶数量，为了衡量哈希冲突的严重程度，**也常被作为哈希表扩容的触发条件**。例如在 Java 中，当负载因子超过 $0.75$ 时，系统会将哈希表容量扩展为原先的 $2$ 倍。 +「负载因子 Load Factor」是哈希表的一个重要概念，其定义为哈希表的元素数量除以桶数量，用于衡量哈希冲突的严重程度，**也常被作为哈希表扩容的触发条件**。例如在 Java 中，当负载因子超过 $0.75$ 时，系统会将哈希表容量扩展为原先的 $2$ 倍。 diff --git a/docs/chapter_sorting/bucket_sort.md b/docs/chapter_sorting/bucket_sort.md index 22ece0854..fdfae75fe 100644 --- a/docs/chapter_sorting/bucket_sort.md +++ b/docs/chapter_sorting/bucket_sort.md @@ -1,6 +1,6 @@ # 桶排序 -前述的几种排序算法都属于“基于比较的排序算法”，它们通过比较元素间的大小来实现排序。此类排序算法的时间复杂度无法超越 $O(n \log n)$ 。接下来，我们将探讨几种“非比较排序算法”，它们的时间复杂度可以达到线性水平。 +前述的几种排序算法都属于“基于比较的排序算法”，它们通过比较元素间的大小来实现排序。此类排序算法的时间复杂度无法超越 $O(n \log n)$ 。接下来，我们将探讨几种“非比较排序算法”，它们的时间复杂度可以达到线性阶。 「桶排序 Bucket Sort」是分治思想的一个典型应用。它通过设置一些具有大小顺序的桶，每个桶对应一个数据范围，将数据平均分配到各个桶中；然后，在每个桶内部分别执行排序；最终按照桶的顺序将所有数据合并。 diff --git a/docs/chapter_sorting/summary.md b/docs/chapter_sorting/summary.md index 492d4366d..9d821e88e 100644 --- a/docs/chapter_sorting/summary.md +++ b/docs/chapter_sorting/summary.md @@ -7,11 +7,10 @@ - 桶排序包含三个步骤：数据分桶、桶内排序和合并结果。它同样体现了分治策略，适用于数据体量很大的情况。桶排序的关键在于对数据进行平均分配。 - 计数排序是桶排序的一个特例，它通过统计数据出现的次数来实现排序。计数排序适用于数据量大但数据范围有限的情况，并且要求数据能够转换为正整数。 - 基数排序通过逐位排序来实现数据排序，要求数据能够表示为固定位数的数字。 +- 总的来说，我们希望找到一种排序算法，具有高效率、稳定、原地以及正向自适应性等优点。然而，正如其他数据结构和算法一样，没有一种排序算法能够同时满足所有这些条件。在实际应用中，我们需要根据数据的特性来选择合适的排序算法。 ![排序算法对比](summary.assets/sorting_algorithms_comparison.png) -- 总的来说，我们希望找到一种排序算法，具有高效率、稳定、原地以及正向自适应性等优点。然而，正如其他数据结构和算法一样，没有一种排序算法能够同时满足所有这些条件。在实际应用中，我们需要根据数据的特性来选择合适的排序算法。 - ## Q & A !!! question "排序算法稳定性在什么情况下是必须的？" @@ -32,9 +31,9 @@ 再深入思考一下，如果我们选择 `nums[right]` 为基准数，那么正好反过来，必须先“从左往右查找”。 -!!! question "关于尾递归优化，为什么选短的数组能保证递归深度不超过 $log n$ ？" +!!! question "关于尾递归优化，为什么选短的数组能保证递归深度不超过 $\log n$ ？" - 递归深度就是当前未返回的递归方法的数量。每轮哨兵划分我们将原数组划分为两个子数组。在尾递归优化后，向下递归的子数组长度最大为原数组的一半长度。假设最差情况，一直为一半长度，那么最终的递归深度就是 $log n$ 。 + 递归深度就是当前未返回的递归方法的数量。每轮哨兵划分我们将原数组划分为两个子数组。在尾递归优化后，向下递归的子数组长度最大为原数组的一半长度。假设最差情况，一直为一半长度，那么最终的递归深度就是 $\log n$ 。 回顾原始的快速排序，我们有可能会连续地递归长度较大的数组，最差情况下为 $n, n - 1, n - 2, ..., 2, 1$ ，从而递归深度为 $n$ 。尾递归优化可以避免这种情况的出现。 diff --git a/docs/chapter_tree/array_representation_of_tree.md b/docs/chapter_tree/array_representation_of_tree.md index 59508c648..efd7e221c 100644 --- a/docs/chapter_tree/array_representation_of_tree.md +++ b/docs/chapter_tree/array_representation_of_tree.md @@ -6,21 +6,21 @@ ## 表示完美二叉树 -先分析一个简单案例，给定一个完美二叉树，我们将节点按照层序遍历的顺序编号（从 $0$ 开始），此时每个节点都对应唯一的索引。 +先分析一个简单案例。给定一个完美二叉树，我们将所有节点按照层序遍历的顺序存储在一个数组中，则每个节点都对应唯一的数组索引。 根据层序遍历的特性，我们可以推导出父节点索引与子节点索引之间的“映射公式”：**若节点的索引为 $i$ ，则该节点的左子节点索引为 $2i + 1$ ，右子节点索引为 $2i + 2$** 。 ![完美二叉树的数组表示](array_representation_of_tree.assets/array_representation_binary_tree.png) -**映射公式的作用相当于链表中的指针**。如果我们将节点按照层序遍历的顺序存储在一个数组中，那么对于数组中的任意节点，我们都可以通过映射公式来访问其子节点。 +**映射公式的角色相当于链表中的指针**。给定数组中的任意一个节点，我们都可以通过映射公式来访问它的左（右）子节点。 ## 表示任意二叉树 -然而，完美二叉树只是一个特例。在二叉树的中间层，通常存在许多 $\text{None}$ ，而层序遍历序列并不包含这些 $\text{None}$ 。我们无法仅凭该序列来推测 $\text{None}$ 的数量和分布位置，**这意味着存在多种二叉树结构都符合该层序遍历序列**。显然在这种情况下，上述的数组表示方法已经失效。 +然而完美二叉树是一个特例，在二叉树的中间层，通常存在许多 $\text{None}$ 。由于层序遍历序列并不包含这些 $\text{None}$ ，因此我们无法仅凭该序列来推测 $\text{None}$ 的数量和分布位置。**这意味着存在多种二叉树结构都符合该层序遍历序列**。显然在这种情况下，上述的数组表示方法已经失效。 ![层序遍历序列对应多种二叉树可能性](array_representation_of_tree.assets/array_representation_without_empty.png) -为了解决此问题，**我们可以考虑在层序遍历序列中显式地写出所有 $\text{None}$**。如下图所示，这样处理后，层序遍历序列就可以唯一表示二叉树了。 +为了解决此问题，**我们可以考虑在层序遍历序列中显式地写出所有 $\text{None}$** 。如下图所示，这样处理后，层序遍历序列就可以唯一表示二叉树了。 === "Java" @@ -42,7 +42,7 @@ ```python title="" # 二叉树的数组表示 - # 直接使用 None 来表示空位 + # 使用 None 来表示空位 tree = [1, 2, 3, 4, None, 6, 7, 8, 9, None, None, 12, None, None, 15] ``` @@ -58,7 +58,7 @@ ```javascript title="" /* 二叉树的数组表示 */ - // 直接使用 null 来表示空位 + // 使用 null 来表示空位 let tree = [1, 2, 3, 4, null, 6, 7, 8, 9, null, null, 12, null, null, 15]; ``` @@ -66,7 +66,7 @@ ```typescript title="" /* 二叉树的数组表示 */ - // 直接使用 null 来表示空位 + // 使用 null 来表示空位 let tree: (number | null)[] = [1, 2, 3, 4, null, 6, 7, 8, 9, null, null, 12, null, null, 15]; ``` @@ -110,10 +110,14 @@ ![任意类型二叉树的数组表示](array_representation_of_tree.assets/array_representation_with_empty.png) -以下为数组表示下二叉树的实现，包括： +值得说明的是，**完全二叉树非常适合使用数组来表示**。回顾完全二叉树的定义，$\text{None}$ 只出现在最底层且靠右的位置，**因此所有 $\text{None}$ 一定出现在层序遍历序列的末尾**。这意味着使用数组表示完全二叉树时，可以省略存储所有 $\text{None}$ ，非常方便。 -- 获取节点数量、节点值、左（右）子节点、父节点等基础操作； -- 获取前序遍历、中序遍历、后序遍历、层序遍历的节点值序列； +![完全二叉树的数组表示](array_representation_of_tree.assets/array_representation_complete_binary_tree.png) + +如下代码给出了数组表示下的二叉树的简单实现，包括以下操作： + +- 给定某节点，获取它的值、左（右）子节点、父节点； +- 获取前序遍历、中序遍历、后序遍历、层序遍历序列； === "Java" @@ -183,18 +187,14 @@ ## 优势与局限性 -二叉树的数组表示存在以下优点： +二叉树的数组表示的优点包括： -- 数组存储在连续的内存空间中，缓存友好，访问与遍历速度较快； +- 数组存储在连续的内存空间中，对缓存友好，访问与遍历速度较快； - 不需要存储指针，比较节省空间； - 允许随机访问节点； 然而，数组表示也具有一些局限性： -- 数组存储需要连续内存空间，因此不适合存储数据量过大的树。 +- 数组存储需要连续内存空间，因此不适合存储数据量过大的树； - 增删节点需要通过数组插入与删除操作实现，效率较低； -- 当二叉树中存在大量 $\text{None}$ 时，数组中包含的节点数据比重较低，空间利用率较低。 - -**完全二叉树非常适合使用数组来表示**。回顾完全二叉树的定义，$\text{None}$ 只出现在最底层且靠右的位置，**这意味着所有 $\text{None}$ 一定出现在层序遍历序列的末尾**。因此，在使用数组表示完全二叉树时，可以省略存储所有 $\text{None}$ 。 - -![完全二叉树的数组表示](array_representation_of_tree.assets/array_representation_complete_binary_tree.png) +- 当二叉树中存在大量 $\text{None}$ 时，数组中包含的节点数据比重较低，空间利用率较低； diff --git a/docs/chapter_tree/binary_tree_traversal.md b/docs/chapter_tree/binary_tree_traversal.md index 4a7925896..c48e552b8 100755 --- a/docs/chapter_tree/binary_tree_traversal.md +++ b/docs/chapter_tree/binary_tree_traversal.md @@ -12,8 +12,6 @@ ![二叉树的层序遍历](binary_tree_traversal.assets/binary_tree_bfs.png) -### 算法实现 - 广度优先遍历通常借助「队列」来实现。队列遵循“先进先出”的规则，而广度优先遍历则遵循“逐层推进”的规则，两者背后的思想是一致的。 === "Java" @@ -82,8 +80,6 @@ [class]{}-[func]{levelOrder} ``` -### 复杂度分析 - **时间复杂度**：所有节点被访问一次，使用 $O(n)$ 时间，其中 $n$ 为节点数量。 **空间复杂度**：在最差情况下，即满二叉树时，遍历到最底层之前，队列中最多同时存在 $\frac{n + 1}{2}$ 个节点，占用 $O(n)$ 空间。 @@ -92,21 +88,11 @@ 相应地，前序、中序和后序遍历都属于「深度优先遍历 Depth-First Traversal」，它体现了一种“先走到尽头，再回溯继续”的遍历方式。 -如下图所示，左侧是深度优先遍历的示意图，右上方是对应的递归实现代码。深度优先遍历就像是绕着整个二叉树的外围“走”一圈，在这个过程中，在每个节点都会遇到三个位置，分别对应前序遍历、中序遍历和后序遍历。 +如下图所示，左侧是深度优先遍历的示意图，右上方是对应的递归代码。深度优先遍历就像是绕着整个二叉树的外围“走”一圈，在这个过程中，在每个节点都会遇到三个位置，分别对应前序遍历、中序遍历和后序遍历。 ![二叉搜索树的前、中、后序遍历](binary_tree_traversal.assets/binary_tree_dfs.png) -
- -| 位置 | 含义 | 此处访问节点时对应 | -| ---------- | ------------------------------------ | ----------------------------- | -| 橙色圆圈处 | 刚进入此节点，即将访问该节点的左子树 | 前序遍历 Pre-Order Traversal | -| 蓝色圆圈处 | 已访问完左子树，即将访问右子树 | 中序遍历 In-Order Traversal | -| 紫色圆圈处 | 已访问完左子树和右子树，即将返回 | 后序遍历 Post-Order Traversal | - -
- -### 算法实现 +以下给出了实现代码，请配合上图理解深度优先遍历的递归过程。 === "Java" @@ -218,11 +204,18 @@ [class]{}-[func]{postOrder} ``` +**时间复杂度**：所有节点被访问一次，使用 $O(n)$ 时间，其中 $n$ 为节点数量。 + +**空间复杂度**：在最差情况下，即树退化为链表时，递归深度达到 $n$ ，系统占用 $O(n)$ 栈帧空间。 + !!! note - 我们也可以仅基于循环实现前、中、后序遍历，有兴趣的同学可以自行实现。 + 我们也可以不使用递归，仅基于迭代实现前、中、后序遍历，有兴趣的同学可以自行研究。 + +下图展示了前序遍历二叉树的递归过程，其可分为“递”和“归”两个逆向的部分： -递归过程可分为“递”和“归”两个相反的部分。“递”表示开启新方法，程序在此过程中访问下一个节点；“归”表示函数返回，代表该节点已经访问完毕。如下图所示，为前序遍历二叉树的递归过程。 +1. “递”表示开启新方法，程序在此过程中访问下一个节点。 +2. “归”表示函数返回，代表当前节点已经访问完毕。 === "<1>" ![前序遍历的递归过程](binary_tree_traversal.assets/preorder_step1.png) @@ -256,9 +249,3 @@ === "<11>" ![preorder_step11](binary_tree_traversal.assets/preorder_step11.png) - -### 复杂度分析 - -**时间复杂度**：所有节点被访问一次，使用 $O(n)$ 时间，其中 $n$ 为节点数量。 - -**空间复杂度**：在最差情况下，即树退化为链表时，递归深度达到 $n$ ，系统占用 $O(n)$ 栈帧空间。