diff --git a/codes/dart/chapter_backtracking/subset_sum_ii.dart b/codes/dart/chapter_backtracking/subset_sum_ii.dart index a545c52ce..877a4a6a5 100644 --- a/codes/dart/chapter_backtracking/subset_sum_ii.dart +++ b/codes/dart/chapter_backtracking/subset_sum_ii.dart @@ -49,6 +49,7 @@ List> subsetSumII(List nums, int target) { return res; } +/* Driver Code */ void main() { List nums = [4, 4, 5]; int target = 9; diff --git a/docs/chapter_array_and_linkedlist/array.md b/docs/chapter_array_and_linkedlist/array.md index fba6faa35..4a348c6d0 100755 --- a/docs/chapter_array_and_linkedlist/array.md +++ b/docs/chapter_array_and_linkedlist/array.md @@ -4,7 +4,7 @@ ![数组定义与存储方式](array.assets/array_definition.png) -**数组初始化**。通常有无初始值和给定初始值两种方式，我们可根据需求选择合适的方法。在未给定初始值的情况下，数组的所有元素通常会被初始化为默认值 $0$ 。 +**数组初始化**。通常有无初始值和给定初始值两种方式，我们可根据需求选择合适的方法。在大多数编程语言中，若未指定初始值，数组的所有元素通常会被默认初始化为 $0$ 。 === "Java" @@ -123,7 +123,7 @@ elementAddr = firtstElementAddr + elementLength * elementIndex 观察上图，我们发现数组首个元素的索引为 $0$ ，这似乎有些反直觉，因为从 $1$ 开始计数会更自然。 - 然而，从地址计算公式的角度看，**索引本质上表示的是内存地址的偏移量**。首个元素的地址偏移量是 $0$ ，因此索引为 $0$ 也是合理的。 + 然而从地址计算公式的角度看，**索引本质上表示的是内存地址的偏移量**。首个元素的地址偏移量是 $0$ ，因此索引为 $0$ 也是合理的。 访问元素的高效性带来了诸多便利。例如，我们可以在 $O(1)$ 时间内随机获取数组中的任意一个元素。 @@ -201,7 +201,7 @@ elementAddr = firtstElementAddr + elementLength * elementIndex ## 数组缺点 -**数组在初始化后长度不可变**。由于系统无法保证数组之后的内存空间是可用的，因此数组长度无法扩展。而若希望扩容数组，则需新建一个数组，然后把原数组元素依次拷贝到新数组，在数组很大的情况下，这是非常耗时的。 +**数组在初始化后长度不可变**。系统无法保证数组之后的内存空间是可用的，因此数组长度无法扩展。而若希望扩容数组，则需新建一个数组，然后把原数组元素依次拷贝到新数组。在数组很大的情况下，这是非常耗时的。 === "Java" @@ -275,7 +275,7 @@ elementAddr = firtstElementAddr + elementLength * elementIndex [class]{}-[func]{extend} ``` -**数组中插入或删除元素效率低下**。如果我们想要在数组中间插入一个元素，由于数组元素在内存中是“紧挨着的”，它们之间没有空间再放任何数据。因此，我们不得不将此索引之后的所有元素都向后移动一位，然后再把元素赋值给该索引。 +**数组中插入或删除元素效率低下**。数组元素在内存中是“紧挨着的”，它们之间没有空间再放任何数据。这意味着如果我们想要在数组中间插入一个元素，就不得不将此索引之后的所有元素都向后移动一位，然后再把元素赋值给该索引。 ![数组插入元素](array.assets/array_insert_element.png) @@ -351,7 +351,7 @@ elementAddr = firtstElementAddr + elementLength * elementIndex [class]{}-[func]{insert} ``` -删除元素也类似，如果我们想要删除索引 $i$ 处的元素，则需要把索引 $i$ 之后的元素都向前移动一位。值得注意的是，删除元素后，原先末尾的元素变得“无意义”了，我们无需特意去修改它。 +删除元素也类似，如果我们想要删除索引 $i$ 处的元素，则需要把索引 $i$ 之后的元素都向前移动一位。值得注意的是，删除元素后，原先末尾的元素变得“无意义”了，所以我们无需特意去修改它。 ![数组删除元素](array.assets/array_remove_element.png) @@ -589,6 +589,6 @@ elementAddr = firtstElementAddr + elementLength * elementIndex - **随机访问**：如果我们想要随机抽取一些样本，那么可以用数组存储，并生成一个随机序列，根据索引实现样本的随机抽取。 - **排序和搜索**：数组是排序和搜索算法最常用的数据结构。例如，快速排序、归并排序、二分查找等都需要在数组上进行。 -- **查找表**：当我们需要快速查找一个元素或者需要查找一个元素的对应关系时，可以使用数组作为查找表。例如，我们有一个字符到其 ASCII 码的映射，可以将字符的 ASCII 码值作为索引，对应的元素存放在数组中的对应位置。 +- **查找表**：当我们需要快速查找一个元素或者需要查找一个元素的对应关系时，可以使用数组作为查找表。假如我们想要实现字符到 ASCII 码的映射，则可以将字符的 ASCII 码值作为索引，对应的元素存放在数组中的对应位置。 - **机器学习**：神经网络中大量使用了向量、矩阵、张量之间的线性代数运算，这些数据都是以数组的形式构建的。数组是神经网络编程中最常使用的数据结构。 -- **数据结构实现**：数组可以用于实现栈、队列、哈希表、堆、图等数据结构。例如，邻接矩阵是图的常见表示之一，它实质上是一个二维数组。 +- **数据结构实现**：数组可以用于实现栈、队列、哈希表、堆、图等数据结构。例如，图的邻接矩阵表示实际上是一个二维数组。 diff --git a/docs/chapter_array_and_linkedlist/linked_list.md b/docs/chapter_array_and_linkedlist/linked_list.md index 2bb2ce5c6..918a774f5 100755 --- a/docs/chapter_array_and_linkedlist/linked_list.md +++ b/docs/chapter_array_and_linkedlist/linked_list.md @@ -4,7 +4,7 @@ 「链表 Linked List」是一种线性数据结构，其每个元素都是一个节点对象，各个节点之间通过指针连接，从当前节点通过指针可以访问到下一个节点。**由于指针记录了下个节点的内存地址，因此无需保证内存地址的连续性**，从而可以将各个节点分散存储在内存各处。 -链表中的「节点 Node」包含两项数据，一是节点「值 Value」，二是指向下一节点的「指针 Pointer」，或称「引用 Reference」。 +链表中的「节点 Node」包含两项数据，一是节点「值 Value」，二是指向下一节点的「引用 Reference」，或称「指针 Pointer」。 ![链表定义与存储方式](linked_list.assets/linkedlist_definition.png) diff --git a/docs/chapter_data_structure/basic_data_types.md b/docs/chapter_data_structure/basic_data_types.md index f17e722ca..4648ea31d 100644 --- a/docs/chapter_data_structure/basic_data_types.md +++ b/docs/chapter_data_structure/basic_data_types.md @@ -36,14 +36,14 @@ 对于上表，需要注意以下几点： - C, C++ 未明确规定基本数据类型大小，而因实现和平台各异。上表遵循 LP64 [数据模型](https://en.cppreference.com/w/cpp/language/types#Properties)，其用于 Unix 64 位操作系统（例如 Linux , macOS）。 -- 字符 `char` 的大小在 C, C++ 中为 1 字节，在大多数编程语言中取决于特定的字符编码方法，详见「字符编码」章节。 -- 现代计算机 CPU 通常将 1 字节作为最小寻址内存单元。因此即使表示布尔量仅需 1 位（$0$ 或 $1$），它在内存中通常被存储为 1 字节。 +- 字符 `char` 的大小在 C, C++ 中为 1 字节，在大多数编程语言中取决于特定的字符编码方法，详见“字符编码”章节。 +- 即使表示布尔量仅需 1 位（$0$ 或 $1$），它在内存中通常被存储为 1 字节。这是因为现代计算机 CPU 通常将 1 字节作为最小寻址内存单元。 -那么，基本数据类型与数据结构之间有什么联系呢？我们知道，数据结构是在计算机中组织与存储数据的方式。它的主语是“结构”，而非“数据”。 +那么，基本数据类型与数据结构之间有什么联系呢？我们知道，数据结构是在计算机中组织与存储数据的方式。它的主语是“结构”而非“数据”。 如果想要表示“一排数字”，我们自然会想到使用数组。这是因为数组的线性结构可以表示数字的相邻关系和顺序关系，但至于存储的内容是整数 `int` 、小数 `float` 、还是字符 `char` ，则与“数据结构”无关。 -换句话说，**基本数据类型提供了数据的“内容类型”，而数据结构提供了数据的“组织方式”**。例如在以下代码中，我们用相同的数据结构（数组）来记录与表示不同的基本数据类型（`int` , `float` , `chat`, `bool`）。 +换句话说，**基本数据类型提供了数据的“内容类型”，而数据结构提供了数据的“组织方式”**。例如以下代码，我们用相同的数据结构（数组）来存储与表示不同的基本数据类型（`int` , `float` , `chat`, `bool`）。 === "Java" diff --git a/docs/chapter_data_structure/character_encoding.md b/docs/chapter_data_structure/character_encoding.md index 380b66d3d..346554c23 100644 --- a/docs/chapter_data_structure/character_encoding.md +++ b/docs/chapter_data_structure/character_encoding.md @@ -1,6 +1,6 @@ # 字符编码 * -在计算机中，所有数据都是以二进制数的形式存储的，字符 `char` 也不例外。为了表示字符，我们需要建立一套「字符集」，规定每个字符和二进制数之间的一一对应关系。有了字符集之后，计算机就可以通过查表完成二进制数到字符的转换。 +在计算机中，所有数据都是以二进制数的形式存储的，字符 `char` 也不例外。为了表示字符，我们需要建立一套“字符集”，规定每个字符和二进制数之间的一一对应关系。有了字符集之后，计算机就可以通过查表完成二进制数到字符的转换。 ## ASCII 字符集 @@ -8,31 +8,33 @@ ![ASCII 码](character_encoding.assets/ascii_table.png) -然而，**ASCII 码仅能够表示英文**。随着计算机的全球化，诞生了一种能够表示更多语言的字符集「EASCII」。它在 ASCII 的 7 位基础上扩展到 8 位，能够表示 256 个不同的字符。在世界范围内，陆续出现了一批适用于不同地区的 EASCII 字符集。这些字符集的前 128 个字符统一为 ASCII 码，后 128 个字符定义不同，以适应不同语言的需求。 +然而，**ASCII 码仅能够表示英文**。随着计算机的全球化，诞生了一种能够表示更多语言的字符集「EASCII」。它在 ASCII 的 7 位基础上扩展到 8 位，能够表示 256 个不同的字符。 + +在世界范围内，陆续出现了一批适用于不同地区的 EASCII 字符集。这些字符集的前 128 个字符统一为 ASCII 码，后 128 个字符定义不同，以适应不同语言的需求。 ## GBK 字符集 -后来人们发现，**EASCII 码仍然无法满足许多语言的字符数量要求**。例如，汉字大约有近十万个，光日常使用的就有几千个。中国国家标准总局于 1980 年发布了「GB2312」字符集，其收录了 6763 个汉字，基本满足了汉字的计算机处理需要。 +后来人们发现，**EASCII 码仍然无法满足许多语言的字符数量要求**。比如汉字大约有近十万个，光日常使用的就有几千个。中国国家标准总局于 1980 年发布了「GB2312」字符集，其收录了 6763 个汉字，基本满足了汉字的计算机处理需要。 -然而，GB2312 无法处理部分的罕见字和繁体字。之后在 GB2312 的基础上，扩展得到了「GBK」字符集，它共收录了 21886 个汉字。在 GBK 编码方案中，ASCII 字符使用一个字节表示，汉字使用两个字节表示。 +然而，GB2312 无法处理部分的罕见字和繁体字。「GBK」字符集是在 GB2312 的基础上扩展得到的，它共收录了 21886 个汉字。在 GBK 的编码方案中，ASCII 字符使用一个字节表示，汉字使用两个字节表示。 ## Unicode 字符集 -随着计算机的蓬勃发展，字符集与编码标准百花齐放，而这带来了许多问题。一方面，这些字符集一般只定义了特定语言的字符，无法在多语言环境下正常工作；另一方面，同一种语言也存在多种字符集标准，如果两台电脑安装的是不同的编码标准，则在信息传递时就会出现乱码。 +随着计算机的蓬勃发展，字符集与编码标准百花齐放，而这带来了许多问题。一方面，这些字符集一般只定义了特定语言的字符，无法在多语言环境下正常工作。另一方面，同一种语言也存在多种字符集标准，如果两台电脑安装的是不同的编码标准，则在信息传递时就会出现乱码。 -那个时代的人们就在想：**如果推出一个足够完整的字符集，将世界范围内的所有语言和符号都收录其中，不就可以解决跨语言环境和乱码问题了吗**？在这种想法的驱动下，一个大而全的字符集 Unicode 应运而生。 +那个时代的研究人员就在想：**如果推出一个足够完整的字符集，将世界范围内的所有语言和符号都收录其中，不就可以解决跨语言环境和乱码问题了吗**？在这种想法的驱动下，一个大而全的字符集 Unicode 应运而生。 「Unicode」的全称为“统一字符编码”，理论上能容纳一百多万个字符。它致力于将全球范围内的字符纳入到统一的字符集之中，提供一种通用的字符集来处理和显示各种语言文字，减少因为编码标准不同而产生的乱码问题。 自 1991 年发布以来，Unicode 不断扩充新的语言与字符。截止 2022 年 9 月，Unicode 已经包含 149186 个字符，包括各种语言的字符、符号、甚至是表情符号等。在庞大的 Unicode 字符集中，常用的字符占用 2 字节，有些生僻的字符占 3 字节甚至 4 字节。 -Unicode 是一种字符集标准，本质上是给每个字符分配一个编号（称为“码点”），**但它并没有规定在计算机中如何存储这些字符码点**。我们不禁会问：当多种长度的 Unicode 码点同时出现在同一个文本中时，系统如何解析字符？例如，给定一个长度为 2 字节的编码，系统如何确认它是一个 2 字节的字符还是两个 1 字节的字符？ +Unicode 是一种字符集标准，本质上是给每个字符分配一个编号（称为“码点”），**但它并没有规定在计算机中如何存储这些字符码点**。我们不禁会问：当多种长度的 Unicode 码点同时出现在同一个文本中时，系统如何解析字符？例如给定一个长度为 2 字节的编码，系统如何确认它是一个 2 字节的字符还是两个 1 字节的字符？ 对于以上问题，**一种直接的解决方案是将所有字符存储为等长的编码**。如下图所示，“Hello”中的每个字符占用 1 字节，“算法”中的每个字符占用 2 字节。我们可以通过高位填 0 ，将“Hello 算法”中的所有字符都编码为 2 字节长度。这样系统就可以每隔 2 字节解析一个字符，恢复出这个短语的内容了。 ![Unicode 编码示例](character_encoding.assets/unicode_hello_algo.png) -然而，ASCII 码已经向我们证明，编码英文只需要 1 字节。若采用上述方案，英文文本占用空间的大小将会是 ASCII 编码下大小的 2 倍，非常浪费内存空间。因此，我们需要一种更加高效的 Unicode 编码方法。 +然而 ASCII 码已经向我们证明，编码英文只需要 1 字节。若采用上述方案，英文文本占用空间的大小将会是 ASCII 编码下大小的两倍，非常浪费内存空间。因此，我们需要一种更加高效的 Unicode 编码方法。 ## UTF-8 编码 @@ -40,35 +42,41 @@ Unicode 是一种字符集标准，本质上是给每个字符分配一个编号 UTF-8 的编码规则并不复杂，分为两种情况： -- 对于长度为 1 字节的字符，将最高位设置为 $0$ 、其余 7 位设置为 Unicode 码点。值得注意的是，ASCII 字符在 Unicode 字符集中占据了前 128 个码点。也就是说，**UTF-8 编码可以向下兼容 ASCII 码**。这意味着我们可以使用 UTF-8 来解析年代久远的 ASCII 码文本。 -- 对于长度为 $n$ 字节的字符（其中 $n > 1$），将首个字节的高 $n$ 位都设置为 $1$ 、第 $n + 1$ 位设置为 $0$ ；从第二个字节开始，将每个字节的高 2 位都设置为 $10$ ；其余所有位用于填充字符的 Unicode 码点。 +1. 对于长度为 1 字节的字符，将最高位设置为 $0$ 、其余 7 位设置为 Unicode 码点。值得注意的是，ASCII 字符在 Unicode 字符集中占据了前 128 个码点。也就是说，**UTF-8 编码可以向下兼容 ASCII 码**。这意味着我们可以使用 UTF-8 来解析年代久远的 ASCII 码文本。 +2. 对于长度为 $n$ 字节的字符（其中 $n > 1$），将首个字节的高 $n$ 位都设置为 $1$ 、第 $n + 1$ 位设置为 $0$ ；从第二个字节开始，将每个字节的高 2 位都设置为 $10$ ；其余所有位用于填充字符的 Unicode 码点。 + +下图展示了“Hello算法”对应的 UTF-8 编码。观察发现，由于最高 $n$ 位都被设置为 $1$ ，因此系统可以通过读取最高位 $1$ 的个数来解析出字符的长度为 $n$ 。 -下图展示了“Hello算法”对应的 UTF-8 编码。将最高 $n$ 位设置为 $1$ 比较容易理解，可以向系统指出字符的长度为 $n$ 。那么，为什么要将其余所有字节的高 2 位都设置为 $10$ 呢？实际上，这个 $10$ 能够起到校验符的作用，因为在 UTF-8 编码规则下，不可能有字符的最高两位是 $10$ 。这是因为长度为 1 字节的字符的最高一位是 $0$ 。假设系统从一个错误的字节开始解析文本，字节头部的 $10$ 能够帮助系统快速的判断出异常。 +但为什么要将其余所有字节的高 2 位都设置为 $10$ 呢？实际上，这个 $10$ 能够起到校验符的作用。假设系统从一个错误的字节开始解析文本，字节头部的 $10$ 能够帮助系统快速的判断出异常。 + +之所以将 $10$ 当作校验符，是因为在 UTF-8 编码规则下，不可能有字符的最高两位是 $10$ 。这个结论可以用反证法来证明：假设一个字符的最高两位是 $10$ ，说明该字符的长度为 $1$ ，对应 ASCII 码。而 ASCII 码的最高位应该是 $0$ ，与假设矛盾。 ![UTF-8 编码示例](character_encoding.assets/utf-8_hello_algo.png) -除了 UTF-8 之外，常见的编码方式还包括 UTF-16 和 UTF-32 。它们为 Unicode 字符集提供了不同的编码方法。 +除了 UTF-8 之外，常见的编码方式还包括： + +- **UTF-16 编码**：使用 2 或 4 个字节来表示一个字符。所有的 ASCII 字符和常用的非英文字符，都用 2 个字节表示；少数字符需要用到 4 个字节表示。对于 2 字节的字符，UTF-16 编码与 Unicode 码点相等。 +- **UTF-32 编码**：每个字符都使用 4 个字节。这意味着 UTF-32 会比 UTF-8 和 UTF-16 更占用空间，特别是对于 ASCII 字符占比较高的文本。 -- **UTF-16 编码**：使用 2 或 4 个字节来表示一个字符。所有的 ASCII 字符和很多常用的非英文字符，都用 2 个字节表示；少数字符需要用到 4 个字节表示。对于 2 字节的字符，UTF-16 编码与 Unicode 码点相等。 -- **UTF-32 编码**：每个字符都使用 4 个字节。这意味着 UTF-32 会比 UTF-8 和 UTF-16 更占用空间，特别是对于主要使用 ASCII 字符的文本。 +从存储空间的角度看，使用 UTF-8 表示英文字符非常高效，因为它仅需 1 个字节；使用 UTF-16 编码某些非英文字符（例如中文）会更加高效，因为它只需要 2 个字节，而 UTF-8 可能需要 3 个字节。 -从存储空间的角度看，使用 UTF-8 表示英文字符非常高效，因为它仅需 1 个字节；使用 UTF-16 编码某些非英文字符（例如中文）会更加高效，因为它只需要 2 个字节，而 UTF-8 可能需要 3 个字节。从兼容性的角度看，UTF-8 的通用性最佳，许多工具和库都优先支持 UTF-8 。 +从兼容性的角度看，UTF-8 的通用性最佳，许多工具和库都优先支持 UTF-8 。 ## 编程语言的字符编码 -对于以往的大多数编程语言，程序运行中的字符串都采用 UTF-16 或 UTF-32 这类等长的编码。这是因为在等长编码下，我们可以将字符串看作数组来处理，具体来说： +对于以往的大多数编程语言，程序运行中的字符串都采用 UTF-16 或 UTF-32 这类等长的编码。这是因为在等长编码下，我们可以将字符串看作数组来处理，其优点包括： - **随机访问**: UTF-16 编码的字符串可以很容易地进行随机访问。UTF-8 是一种变长编码，要找到第 $i$ 个字符，我们需要从字符串的开始处遍历到第 $i$ 个字符，这需要 $O(n)$ 的时间。 - **字符计数**: 与随机访问类似，计算 UTF-16 字符串的长度也是 $O(1)$ 的操作。但是，计算 UTF-8 编码的字符串的长度需要遍历整个字符串。 - **字符串操作**: 在 UTF-16 编码的字符串中，很多字符串操作（如分割、连接、插入、删除等）都更容易进行。在 UTF-8 编码的字符串上进行这些操作通常需要额外的计算，以确保不会产生无效的 UTF-8 编码。 -编程语言的字符编码方案设计是一个很有趣的话题，涉及到许多因素： +实际上，编程语言的字符编码方案设计是一个很有趣的话题，其涉及到许多因素： - Java 的 `String` 类型使用 UTF-16 编码，每个字符占用 2 字节。这是因为 Java 语言设计之初，人们认为 16 位足以表示所有可能的字符。然而，这是一个不正确的判断。后来 Unicode 规范扩展到了超过 16 位，所以 Java 中的字符现在可能由一对 16 位的值（称为“代理对”）表示。 - JavaScript 和 TypeScript 的字符串使用 UTF-16 编码的原因与 Java 类似。当 JavaScript 语言在 1995 年被 Netscape 公司首次引入时，Unicode 还处于相对早期的阶段，那时候使用 16 位的编码就足够表示所有的 Unicode 字符了。 - C# 使用 UTF-16 编码，主要因为 .NET 平台是由 Microsoft 设计的，而 Microsoft 的很多技术，包括 Windows 操作系统，都广泛地使用 UTF-16 编码。 -由于以上编程语言对字符数量的低估，它们不得不采取“代理对”的方式来表示超过 16 位长度的 Unicode 字符。这是一个不得已为之的无奈之举。一方面，包含代理对的字符串中，一个字符可能占用 2 字节或 4 字节，因此丧失了等长编码的优势。另一方面，处理代理对需要增加额外代码，这增加了编程的复杂性和 Debug 难度。 +由于以上编程语言对字符数量的低估，它们不得不采取“代理对”的方式来表示超过 16 位长度的 Unicode 字符。这是一个不得已为之的无奈之举。一方面，包含代理对的字符串中，一个字符可能占用 2 字节或 4 字节，从而丧失了等长编码的优势。另一方面，处理代理对需要增加额外代码，这增加了编程的复杂性和 Debug 难度。 出于以上原因，部分编程语言提出了不同的编码方案： @@ -76,4 +84,4 @@ UTF-8 的编码规则并不复杂，分为两种情况： - Go 语言的 `string` 类型在内部使用 UTF-8 编码。Go 语言还提供了 `rune` 类型，它用于表示单个 Unicode 码点。 - Rust 语言的 str 和 String 类型在内部使用 UTF-8 编码。Rust 也提供了 char 类型，用于表示单个 Unicode 码点。 -需要注意的是，以上讨论的都是字符串在编程语言中的存储方式，**这和字符串如何在文件中存储或在网络中传输是两个不同的问题**。在文件存储或网络传输中，我们一般会将字符串编码为 UTF-8 格式，以达到最优的兼容性和空间效率。 +需要注意的是，以上讨论的都是字符串在编程语言中的存储方式，**这和字符串如何在文件中存储或在网络中传输是两个不同的问题**。在文件存储或网络传输中，我们通常会将字符串编码为 UTF-8 格式，以达到最优的兼容性和空间效率。 diff --git a/docs/chapter_data_structure/classification_of_data_structure.md b/docs/chapter_data_structure/classification_of_data_structure.md index aaa037985..40bdef27f 100644 --- a/docs/chapter_data_structure/classification_of_data_structure.md +++ b/docs/chapter_data_structure/classification_of_data_structure.md @@ -1,12 +1,12 @@ # 数据结构分类 -数据结构可以从逻辑结构和物理结构两个维度进行分类。 +常见的数据结构包括数组、链表、栈、队列、哈希表、树、堆、图，它们可以从“逻辑结构”和“物理结构”两个维度进行分类。 ## 逻辑结构：线性与非线性 **「逻辑结构」揭示了数据元素之间的逻辑关系**。在数组和链表中，数据按照顺序依次排列，体现了数据之间的线性关系；而在树中，数据从顶部向下按层次排列，表现出祖先与后代之间的派生关系；图则由节点和边构成，反映了复杂的网络关系。 -逻辑结构通常分为“线性”和“非线性”两类。线性结构比较直观，指数据在逻辑关系上呈线性排列；非线性结构则相反，呈非线性排列。 +逻辑结构可被分为“线性”和“非线性”两大类。线性结构比较直观，指数据在逻辑关系上呈线性排列；非线性结构则相反，呈非线性排列。 - **线性数据结构**：数组、链表、栈、队列、哈希表。 - **非线性数据结构**：树、堆、图、哈希表。 @@ -15,27 +15,27 @@ 非线性数据结构可以进一步被划分为树形结构和网状结构。 -- **线性结构**：数组、链表、队列、栈、哈希表，元素存在一对一的顺序关系。 -- **树形结构**：树、堆、哈希表，元素存在一对多的关系。 -- **网状结构**：图，元素存在多对多的关系。 +- **线性结构**：数组、链表、队列、栈、哈希表，元素之间是一对一的顺序关系。 +- **树形结构**：树、堆、哈希表，元素之间是一对多的关系。 +- **网状结构**：图，元素之间是多对多的关系。 ## 物理结构：连续与离散 在计算机中，内存和硬盘是两种主要的存储硬件设备。硬盘主要用于长期存储数据，容量较大（通常可达到 TB 级别）、速度较慢。内存用于运行程序时暂存数据，速度较快，但容量较小（通常为 GB 级别）。 -**在算法运行过程中，相关数据都存储在内存中**。下图展示了一个计算机内存条，其中每个黑色方块都包含一块内存空间。我们可以将内存想象成一个巨大的 Excel 表格，其中每个单元格都可以存储 1 byte 的数据，在算法运行时，所有数据都被存储在这些单元格中。 +**在算法运行过程中，相关数据都存储在内存中**。下图展示了一个计算机内存条，其中每个黑色方块都包含一块内存空间。我们可以将内存想象成一个巨大的 Excel 表格，其中每个单元格都可以存储一定大小的数据，在算法运行时，所有数据都被存储在这些单元格中。 -**系统通过「内存地址 Memory Location」来访问目标内存位置的数据**。计算机根据特定规则为表格中的每个单元格分配编号，确保每个内存空间都有唯一的内存地址。有了这些地址，程序便可以访问内存中的数据。 +**系统通过内存地址来访问目标位置的数据**。计算机根据特定规则为表格中的每个单元格分配编号，确保每个内存空间都有唯一的内存地址。有了这些地址，程序便可以访问内存中的数据。 ![内存条、内存空间、内存地址](classification_of_data_structure.assets/computer_memory_location.png) -内存是所有程序的共享资源，当内存被某个程序占用时，其他程序无法同时使用。**因此，在数据结构与算法的设计中，内存资源是一个重要的考虑因素**。例如，算法所占用的内存峰值不应超过系统剩余空闲内存；如果运行的程序很多并且缺少大量连续的内存空间，那么所选用的数据结构必须能够存储在离散的内存空间内。 +内存是所有程序的共享资源，当某块内存被某个程序占用时，则无法被其他程序同时使用了。**因此在数据结构与算法的设计中，内存资源是一个重要的考虑因素**。比如，算法所占用的内存峰值不应超过系统剩余空闲内存；如果缺少连续大块的内存空间，那么所选用的数据结构必须能够存储在离散的内存空间内。 -**「物理结构」反映了数据在计算机内存中的存储方式**，可分为数组的连续空间存储和链表的离散空间存储。物理结构从底层决定了数据的访问、更新、增删等操作方法，同时在时间效率和空间效率方面呈现出互补的特点。 +**「物理结构」反映了数据在计算机内存中的存储方式**，可分为连续空间存储（数组）和离散空间存储（链表）。物理结构从底层决定了数据的访问、更新、增删等操作方法，同时在时间效率和空间效率方面呈现出互补的特点。 ![连续空间存储与离散空间存储](classification_of_data_structure.assets/classification_phisical_structure.png) -**所有数据结构都是基于数组、链表或二者的组合实现的**。例如，栈和队列既可以使用数组实现，也可以使用链表实现；而哈希表的实现可能同时包含数组和链表。 +值得说明的是，**所有数据结构都是基于数组、链表或二者的组合实现的**。例如，栈和队列既可以使用数组实现，也可以使用链表实现；而哈希表的实现可能同时包含数组和链表。 - **基于数组可实现**：栈、队列、哈希表、树、堆、图、矩阵、张量（维度 $\geq 3$ 的数组）等。 - **基于链表可实现**：栈、队列、哈希表、树、堆、图等。 @@ -44,4 +44,4 @@ !!! tip - 如若感觉理解物理结构有困难，建议先阅读下一章“数组与链表”，然后再回头理解物理结构的含义。数组与链表是其他所有数据结构的基石，建议你投入更多时间深入了解这两种基本数据结构。 + 如若感觉理解物理结构有困难，建议先阅读下一章“数组与链表”，然后再回顾本节内容。 diff --git a/docs/chapter_data_structure/number_encoding.md b/docs/chapter_data_structure/number_encoding.md index 557608098..b95c19eb2 100644 --- a/docs/chapter_data_structure/number_encoding.md +++ b/docs/chapter_data_structure/number_encoding.md @@ -2,11 +2,13 @@ !!! note - 在本书中，标题带有的 * 符号的是选读章节。如果你时间有限或感到理解困难，建议先跳过，等学完必读章节后再单独攻克。 + 在本书中，标题带有的 * 符号的是选读章节。如果你时间有限或感到理解困难，可以先跳过，等学完必读章节后再单独攻克。 ## 原码、反码和补码 -从上一节的表格中我们发现，所有整数类型能够表示的负数都比正数多一个。例如，`byte` 的取值范围是 $[-128, 127]$ 。这个现象比较反直觉，它的内在原因涉及到原码、反码、补码的相关知识。在展开分析之前，我们首先给出三者的定义： +从上一节的表格中我们发现，所有整数类型能够表示的负数都比正数多一个。例如，`byte` 的取值范围是 $[-128, 127]$ 。这个现象比较反直觉，它的内在原因涉及到原码、反码、补码的相关知识。 + +在展开分析之前，我们首先给出三者的定义： - **原码**：我们将数字的二进制表示的最高位视为符号位，其中 $0$ 表示正数，$1$ 表示负数，其余位表示数字的值。 - **反码**：正数的反码与其原码相同，负数的反码是对其原码除符号位外的所有位取反。 @@ -14,7 +16,7 @@ ![原码、反码与补码之间的相互转换](number_encoding.assets/1s_2s_complement.png) -显然，「原码」最为直观，**然而数字却是以「补码」的形式存储在计算机中的**。这是因为原码存在一些局限性。 +显然「原码」最为直观。但实际上，**数字是以「补码」的形式存储在计算机中的**。这是因为原码存在一些局限性。 一方面，**负数的原码不能直接用于运算**。例如，我们在原码下计算 $1 + (-2)$ ，得到的结果是 $-3$ ，这显然是不对的。 @@ -27,20 +29,20 @@ $$ \end{aligned} $$ -为了解决此问题，计算机引入了「反码」。例如，我们先将原码转换为反码，并在反码下计算 $1 + (-2)$ ，并将结果从反码转化回原码，则可得到正确结果 $-1$ 。 +为了解决此问题，计算机引入了「反码」。如果我们先将原码转换为反码，并在反码下计算 $1 + (-2)$ ，最后将结果从反码转化回原码，则可得到正确结果 $-1$ 。 $$ \begin{aligned} & 1 + (-2) \newline -& = 0000 \space 0001 \space \text{(原码)} + 1000 \space 0010 \space \text{(原码)} \newline +& \rightarrow 0000 \space 0001 \space \text{(原码)} + 1000 \space 0010 \space \text{(原码)} \newline & = 0000 \space 0001 \space \text{(反码)} + 1111 \space 1101 \space \text{(反码)} \newline & = 1111 \space 1110 \space \text{(反码)} \newline & = 1000 \space 0001 \space \text{(原码)} \newline -& = -1 +& \rightarrow -1 \end{aligned} $$ -另一方面，**数字零的原码有 $+0$ 和 $-0$ 两种表示方式**。这意味着数字零对应着两个不同的二进制编码，而这可能会带来歧义问题。例如，在条件判断中，如果没有区分正零和负零，可能会导致错误的判断结果。如果我们想要处理正零和负零歧义，则需要引入额外的判断操作，其可能会降低计算机的运算效率。 +另一方面，**数字零的原码有 $+0$ 和 $-0$ 两种表示方式**。这意味着数字零对应着两个不同的二进制编码，其可能会带来歧义。比如在条件判断中，如果没有区分正零和负零，则可能会导致判断结果出错。而如果我们想要处理正零和负零歧义，则需要引入额外的判断操作，其可能会降低计算机的运算效率。 $$ \begin{aligned} @@ -49,7 +51,7 @@ $$ \end{aligned} $$ -与原码一样，反码也存在正负零歧义问题。为此，计算机进一步引入了「补码」。那么，补码有什么作用呢？我们先来分析一下负零的补码的计算过程： +与原码一样，反码也存在正负零歧义问题，因此计算机进一步引入了「补码」。我们先来观察一下负零的原码、反码、补码的转换过程： $$ \begin{aligned} @@ -59,30 +61,30 @@ $$ \end{aligned} $$ -在负零的反码基础上加 $1$ 会产生进位，而由于 byte 的长度只有 8 位，因此溢出到第 9 位的 $1$ 会被舍弃。**从而得到负零的补码为 $0000 \space 0000$ ，与正零的补码相同**。这意味着在补码表示中只存在一个零，从而解决了正负零歧义问题。 +在负零的反码基础上加 $1$ 会产生进位，但 `byte` 类型的长度只有 8 位，因此溢出到第 9 位的 $1$ 会被舍弃。也就是说，**负零的补码为 $0000 \space 0000$ ，与正零的补码相同**。这意味着在补码表示中只存在一个零，正负零歧义从而得到解决。 -还剩余最后一个疑惑：byte 的取值范围是 $[-128, 127]$ ，多出来的一个负数 $-128$ 是如何得到的呢？我们注意到，区间 $[-127, +127]$ 内的所有整数都有对应的原码、反码和补码，并且原码和补码之间是可以互相转换的。 +还剩余最后一个疑惑：`byte` 类型的取值范围是 $[-128, 127]$ ，多出来的一个负数 $-128$ 是如何得到的呢？我们注意到，区间 $[-127, +127]$ 内的所有整数都有对应的原码、反码和补码，并且原码和补码之间是可以互相转换的。 然而，**补码 $1000 \space 0000$ 是一个例外，它并没有对应的原码**。根据转换方法，我们得到该补码的原码为 $0000 \space 0000$ 。这显然是矛盾的，因为该原码表示数字 $0$ ，它的补码应该是自身。计算机规定这个特殊的补码 $1000 \space 0000$ 代表 $-128$ 。实际上，$(-1) + (-127)$ 在补码下的计算结果就是 $-128$ 。 $$ \begin{aligned} & (-127) + (-1) \newline -& = 1111 \space 1111 \space \text{(原码)} + 1000 \space 0001 \space \text{(原码)} \newline +& \rightarrow 1111 \space 1111 \space \text{(原码)} + 1000 \space 0001 \space \text{(原码)} \newline & = 1000 \space 0000 \space \text{(反码)} + 1111 \space 1110 \space \text{(反码)} \newline & = 1000 \space 0001 \space \text{(补码)} + 1111 \space 1111 \space \text{(补码)} \newline & = 1000 \space 0000 \space \text{(补码)} \newline -& = -128 +& \rightarrow -128 \end{aligned} $$ -你可能已经发现，上述的所有计算都是加法运算。这暗示着一个重要事实：**计算机内部的硬件电路主要是基于加法运算设计的**。这是因为加法运算相对于其他运算（比如乘法、除法和减法）来说，硬件实现起来更简单，更容易进行并行化处理，从而提高运算速度。 +你可能已经发现，上述的所有计算都是加法运算。这暗示着一个重要事实：**计算机内部的硬件电路主要是基于加法运算设计的**。这是因为加法运算相对于其他运算（比如乘法、除法和减法）来说，硬件实现起来更简单，更容易进行并行化处理，运算速度更快。 -然而，这并不意味着计算机只能做加法。**通过将加法与一些基本逻辑运算结合，计算机能够实现各种其他的数学运算**。例如，计算减法 $a - b$ 可以转换为计算加法 $a + (-b)$ ；计算乘法和除法可以转换为计算多次加法或减法。 +请注意，这并不意味着计算机只能做加法。**通过将加法与一些基本逻辑运算结合，计算机能够实现各种其他的数学运算**。例如，计算减法 $a - b$ 可以转换为计算加法 $a + (-b)$ ；计算乘法和除法可以转换为计算多次加法或减法。 -现在，我们可以总结出计算机使用补码的原因：基于补码表示，计算机可以用同样的电路和操作来处理正数和负数的加法，不需要设计特殊的硬件电路来处理减法，并且无需特别处理正负零的歧义问题。这大大简化了硬件设计，并提高了运算效率。 +现在我们可以总结出计算机使用补码的原因：基于补码表示，计算机可以用同样的电路和操作来处理正数和负数的加法，不需要设计特殊的硬件电路来处理减法，并且无需特别处理正负零的歧义问题。这大大简化了硬件设计，提高了运算效率。 -补码的设计非常精妙，由于篇幅关系我们先介绍到这里。建议有兴趣的读者进一步深度了解。 +补码的设计非常精妙，因篇幅关系我们就先介绍到这里，建议有兴趣的读者进一步深度了解。 ## 浮点数编码 @@ -123,7 +125,7 @@ $$ ![IEEE 754 标准下的 float 表示方式](number_encoding.assets/ieee_754_float.png) -以上图为例，$\mathrm{S} = 0$ ， $\mathrm{E} = 124$ ，$\mathrm{N} = 2^{-2} + 2^{-3} = 0.375$ ，易得 +给定一个示例数据 $\mathrm{S} = 0$ ， $\mathrm{E} = 124$ ，$\mathrm{N} = 2^{-2} + 2^{-3} = 0.375$ ，则有： $$ \text { val } = (-1)^0 \times 2^{124 - 127} \times (1 + 0.375) = 0.171875 diff --git a/docs/chapter_data_structure/summary.md b/docs/chapter_data_structure/summary.md index 74cdc549e..2f17c078b 100644 --- a/docs/chapter_data_structure/summary.md +++ b/docs/chapter_data_structure/summary.md @@ -1,15 +1,10 @@ # 小结 -**数据结构分类** - - 数据结构可以从逻辑结构和物理结构两个角度进行分类。逻辑结构描述了数据元素之间的逻辑关系，而物理结构描述了数据在计算机内存中的存储方式。 - 常见的逻辑结构包括线性、树状和网状等。通常我们根据逻辑结构将数据结构分为线性（数组、链表、栈、队列）和非线性（树、图、堆）两种。哈希表的实现可能同时包含线性和非线性结构。 - 当程序运行时，数据被存储在计算机内存中。每个内存空间都拥有对应的内存地址，程序通过这些内存地址访问数据。 - 物理结构主要分为连续空间存储（数组）和离散空间存储（链表）。所有数据结构都是由数组、链表或两者的组合实现的。 - -**数据类型与编码** - -- 计算机中的基本数据类型包括整数 byte, short, int, long 、浮点数 float, double 、字符 char 和布尔 boolean 。它们的取值范围取决于占用空间大小和表示方式。 +- 计算机中的基本数据类型包括整数 `byte` , `short` , `int` , `long` 、浮点数 `float` , `double` 、字符 `char` 和布尔 `boolean` 。它们的取值范围取决于占用空间大小和表示方式。 - 原码、反码和补码是在计算机中编码数字的三种方法，它们之间是可以相互转换的。整数的原码的最高位是符号位，其余位是数字的值。 - 整数在计算机中是以补码的形式存储的。在补码表示下，计算机可以对正数和负数的加法一视同仁，不需要为减法操作单独设计特殊的硬件电路，并且不存在正负零歧义的问题。 - 浮点数的编码由 1 位符号位、8 位指数位和 23 位分数位构成。由于存在指数位，浮点数的取值范围远大于整数，代价是牺牲了精度。 @@ -20,8 +15,8 @@ !!! question "为什么哈希表同时包含线性数据结构和非线性数据结构？" - 哈希表底层是数组，而为了解决哈希冲突，我们可能会使用“拉链法”（后续散列表章节会讲）。在拉链法中，数组中每个地址（桶）指向一个链表；当这个链表长度超过一定阈值时，又可能被转化为树（通常为红黑树）。因此，哈希表可能同时包含线性（数组、链表）和非线性（树）数据结构。 + 哈希表底层是数组，而为了解决哈希冲突，我们可能会使用“链式地址”（后续散列表章节会讲）。在拉链法中，数组中每个地址（桶）指向一个链表；当这个链表长度超过一定阈值时，又可能被转化为树（通常为红黑树）。因此，哈希表可能同时包含线性（数组、链表）和非线性（树）数据结构。 -!!! question "char 类型的长度是 1 byte 吗？" +!!! question "`char` 类型的长度是 1 byte 吗？" - char 类型的长度由编程语言采用的编码方法决定。例如，Java, JS, TS, C# 都采用 UTF-16 编码（保存 Unicode 码点），因此 char 类型的长度为 2 bytes 。 + `char` 类型的长度由编程语言采用的编码方法决定。例如，Java, JS, TS, C# 都采用 UTF-16 编码（保存 Unicode 码点），因此 char 类型的长度为 2 bytes 。 diff --git a/docs/chapter_dynamic_programming/unbounded_knapsack_problem.assets/unbounded_knapsack_dp_comp_step2.png b/docs/chapter_dynamic_programming/unbounded_knapsack_problem.assets/unbounded_knapsack_dp_comp_step2.png index 85fc94a01..42a766f4c 100644 Binary files a/docs/chapter_dynamic_programming/unbounded_knapsack_problem.assets/unbounded_knapsack_dp_comp_step2.png and b/docs/chapter_dynamic_programming/unbounded_knapsack_problem.assets/unbounded_knapsack_dp_comp_step2.png differ diff --git a/docs/chapter_dynamic_programming/unbounded_knapsack_problem.assets/unbounded_knapsack_dp_comp_step3.png b/docs/chapter_dynamic_programming/unbounded_knapsack_problem.assets/unbounded_knapsack_dp_comp_step3.png index 5d4481b9d..7cfd39af5 100644 Binary files a/docs/chapter_dynamic_programming/unbounded_knapsack_problem.assets/unbounded_knapsack_dp_comp_step3.png and b/docs/chapter_dynamic_programming/unbounded_knapsack_problem.assets/unbounded_knapsack_dp_comp_step3.png differ diff --git a/docs/chapter_dynamic_programming/unbounded_knapsack_problem.assets/unbounded_knapsack_dp_comp_step4.png b/docs/chapter_dynamic_programming/unbounded_knapsack_problem.assets/unbounded_knapsack_dp_comp_step4.png index 1a4d6d294..48239029a 100644 Binary files a/docs/chapter_dynamic_programming/unbounded_knapsack_problem.assets/unbounded_knapsack_dp_comp_step4.png and b/docs/chapter_dynamic_programming/unbounded_knapsack_problem.assets/unbounded_knapsack_dp_comp_step4.png differ diff --git a/docs/chapter_dynamic_programming/unbounded_knapsack_problem.assets/unbounded_knapsack_dp_comp_step5.png b/docs/chapter_dynamic_programming/unbounded_knapsack_problem.assets/unbounded_knapsack_dp_comp_step5.png index 2dcf24978..2bb6ab3d5 100644 Binary files a/docs/chapter_dynamic_programming/unbounded_knapsack_problem.assets/unbounded_knapsack_dp_comp_step5.png and b/docs/chapter_dynamic_programming/unbounded_knapsack_problem.assets/unbounded_knapsack_dp_comp_step5.png differ diff --git a/docs/chapter_dynamic_programming/unbounded_knapsack_problem.md b/docs/chapter_dynamic_programming/unbounded_knapsack_problem.md index b86439841..8657a55ca 100644 --- a/docs/chapter_dynamic_programming/unbounded_knapsack_problem.md +++ b/docs/chapter_dynamic_programming/unbounded_knapsack_problem.md @@ -206,7 +206,7 @@ $$ !!! question - 给定 $n$ 种硬币，第 $i$ 个硬币的面值为 $coins[i - 1]$ ，目标金额为 $amt$ ，**每种硬币可以重复选取**，问能够凑出目标金额的最少硬币个数。如果无法凑出目标金额则返回 $-1$ 。 + 给定 $n$ 种硬币，第 $i$ 种硬币的面值为 $coins[i - 1]$ ，目标金额为 $amt$ ，**每种硬币可以重复选取**，问能够凑出目标金额的最少硬币个数。如果无法凑出目标金额则返回 $-1$ 。 ![零钱兑换问题的示例数据](unbounded_knapsack_problem.assets/coin_change_example.png) @@ -218,7 +218,7 @@ $$ **第一步：思考每轮的决策，定义状态，从而得到 $dp$ 表** -状态 $[i, a]$ 对应的子问题为：**前 $i$ 个硬币能够凑出金额 $a$ 的最少硬币个数**，记为 $dp[i, a]$ 。 +状态 $[i, a]$ 对应的子问题为：**前 $i$ 种硬币能够凑出金额 $a$ 的最少硬币个数**，记为 $dp[i, a]$ 。 二维 $dp$ 表的尺寸为 $(n+1) \times (amt+1)$ 。 @@ -446,11 +446,11 @@ $$ !!! question - 给定 $n$ 种硬币，第 $i$ 个硬币的面值为 $coins[i - 1]$ ，目标金额为 $amt$ ，每种硬币可以重复选取，**问在凑出目标金额的硬币组合数量**。 + 给定 $n$ 种硬币，第 $i$ 种硬币的面值为 $coins[i - 1]$ ，目标金额为 $amt$ ，每种硬币可以重复选取，**问在凑出目标金额的硬币组合数量**。 ![零钱兑换问题 II 的示例数据](unbounded_knapsack_problem.assets/coin_change_ii_example.png) -相比于上一题，本题目标是组合数量，因此子问题变为：**前 $i$ 个硬币能够凑出金额 $a$ 的组合数量**。而 $dp$ 表仍然是尺寸为 $(n+1) \times (amt + 1)$ 的二维矩阵。 +相比于上一题，本题目标是组合数量，因此子问题变为：**前 $i$ 种硬币能够凑出金额 $a$ 的组合数量**。而 $dp$ 表仍然是尺寸为 $(n+1) \times (amt + 1)$ 的二维矩阵。 当前状态的组合数量等于不选当前硬币与选当前硬币这两种决策的组合数量之和。状态转移方程为： diff --git a/docs/chapter_greedy/greedy_algorithm.md b/docs/chapter_greedy/greedy_algorithm.md index dbd595757..a60efd5bd 100644 --- a/docs/chapter_greedy/greedy_algorithm.md +++ b/docs/chapter_greedy/greedy_algorithm.md @@ -11,7 +11,7 @@ !!! question - 给定 $n$ 种硬币，第 $i$ 个硬币的面值为 $coins[i - 1]$ ，目标金额为 $amt$ ，每种硬币可以重复选取，问能够凑出目标金额的最少硬币个数。如果无法凑出目标金额则返回 $-1$ 。 + 给定 $n$ 种硬币，第 $i$ 种硬币的面值为 $coins[i - 1]$ ，目标金额为 $amt$ ，每种硬币可以重复选取，问能够凑出目标金额的最少硬币个数。如果无法凑出目标金额则返回 $-1$ 。 这道题的贪心策略在生活中很常见：给定目标金额，**我们贪心地选择不大于且最接近它的硬币**，不断循环该步骤，直至凑出目标金额为止。