This commit is contained in:
krahets
2023-08-20 14:52:31 +08:00
parent 44a8568356
commit 68e11cfa34
40 changed files with 239 additions and 235 deletions

View File

@@ -13,9 +13,9 @@ icon: material/timer-sand
!!! abstract
复杂度犹如浩瀚的算法宇宙中的指南针
复杂度犹如浩瀚的算法宇宙中的时空向导
引导我们在时间与空间维度上深入探索,寻找更优雅的解决方案。
带领我们在时间与空间这两个维度上深入探索,寻找更优雅的解决方案。
## 本章内容

View File

@@ -4,12 +4,12 @@ comments: true
# 2.1   算法效率评估
在算法设计中,我们先后追求以下两个层面的目标
在算法设计中,我们先后追求以下两个层面的目标
1. **找到问题解法**:算法需要在规定的输入范围内,可靠地求得问题的正确解。
2. **寻求最优解法**:同一个问题可能存在多种解法,我们希望找到尽可能高效的算法。
因此在能够解决问题的前提下,算法效率成为主要评价维度,包括:
因此在能够解决问题的前提下,算法效率成为衡量算法优劣的主要评价指标,它包括以下两个维度。
- **时间效率**:算法运行速度的快慢。
- **空间效率**:算法占用内存空间的大小。
@@ -22,28 +22,28 @@ comments: true
假设我们现在有算法 `A` 和算法 `B` ,它们都能解决同一问题,现在需要对比这两个算法的效率。最直接的方法是找一台计算机,运行这两个算法,并监控记录它们的运行时间和内存占用情况。这种评估方式能够反映真实情况,但也存在较大局限性。
**难以排除测试环境的干扰因素**。硬件配置会影响算法的性能表现。比如在某台计算机中,算法 `A` 的运行时间比算法 `B` 短;但在另一台配置不同的计算机中,我们可能得到相反的测试结果。这意味着我们需要在各种机器上进行测试,统计平均效率,而这是不现实的。
一方面,**难以排除测试环境的干扰因素**。硬件配置会影响算法的性能表现。比如在某台计算机中,算法 `A` 的运行时间比算法 `B` 短;但在另一台配置不同的计算机中,我们可能得到相反的测试结果。这意味着我们需要在各种机器上进行测试,统计平均效率,而这是不现实的。
**展开完整测试非常耗费资源**。随着输入数据量的变化,算法会表现出不同的效率。例如,在输入数据量较小时,算法 `A` 的运行时间比算法 `B` 更少;而输入数据量较大时,测试结果可能恰恰相反。因此,为了得到有说服力的结论,我们需要测试各种规模的输入数据,而这样需要耗费大量的计算资源。
另一方面,**展开完整测试非常耗费资源**。随着输入数据量的变化,算法会表现出不同的效率。例如,在输入数据量较小时,算法 `A` 的运行时间比算法 `B` 更少;而输入数据量较大时,测试结果可能恰恰相反。因此,为了得到有说服力的结论,我们需要测试各种规模的输入数据,而这样需要耗费大量的计算资源。
## 2.1.2   理论估算
由于实际测试具有较大的局限性,我们可以考虑仅通过一些计算来评估算法的效率。这种估算方法被称为「渐近复杂度分析 Asymptotic Complexity Analysis」简称「复杂度分析」。
由于实际测试具有较大的局限性,我们可以考虑仅通过一些计算来评估算法的效率。这种估算方法被称为「渐近复杂度分析 asymptotic complexity analysis」简称「复杂度分析」。
复杂度分析评估的是算法行所需的时间和空间资源**它被表示为一个函数,描述了随着输入数据大小的增加,算法所需时间(空间)的增长趋势**。这个定义有些拗口,我们可以将其分为三个重点来理解
复杂度分析评估的是算法行所需的时间和空间资源**它描述了随着输入数据大小的增加,算法所需时间(空间)的增长趋势**。这个定义有些拗口,我们可以将其分为三个重点来理解
1. “时间空间”分别对应「时间复杂度 Time Complexity」和「空间复杂度 Space Complexity」。
1. “时间空间资源”分别对应「时间复杂度 time complexity」和「空间复杂度 space complexity」。
2. “随着输入数据大小的增加”意味着复杂度反映了算法运行效率与输入数据体量之间的关系。
3. “增长趋势”表示复杂度分析关注的是算法时间与空间的增长趋势,而非具体的运行时间或占用空间。
**复杂度分析克服了实际测试方法的弊端**。首先,它独立于测试环境,分析结果适用于所有运行平台。其次,它可以体现不同数据量下的算法效率,尤其是在大数据量下的算法性能。
如果你对复杂度分析的概念仍感到困惑,无担心,我们会在后续章节详细介绍。
如果你对复杂度分析的概念仍感到困惑,无担心,我们会在后续章节详细介绍。
## 2.1.3   复杂度的重要性
复杂度分析为我们提供了一把评估算法效率的“标尺”,帮助我们衡量了执行某个算法所需的时间和空间资源,并使我们能够对比不同算法之间的效率。
复杂度是个数学概念,对于初学者可能比较抽象,学习难度相对较高。从这个角度看,复杂度分析可能不太适合作为第章的内容。
复杂度是个数学概念,对于初学者可能比较抽象,学习难度相对较高。从这个角度看,复杂度分析可能不太适合作为第 1 章的内容。
然而,当我们讨论某个数据结构或算法的特点时,难以避免要分析其运行速度和空间使用情况。因此,在深入学习数据结构与算法之前,**建议你先对复杂度建立初步的了解,能够完成简单算法的复杂度分析**。
然而,当我们讨论某个数据结构或算法的特点时,难以避免要分析其运行速度和空间使用情况。因此,在深入学习数据结构与算法之前,**建议你先对复杂度建立初步的了解,以便能够完成简单算法的复杂度分析**。

View File

@@ -4,25 +4,25 @@ comments: true
# 2.3   空间复杂度
「空间复杂度 Space Complexity」用于衡量算法占用内存空间随着数据量变大时的增长趋势。这个概念与时间复杂度非常类似只需将“运行时间”替换为“占用内存空间”。
「空间复杂度 space complexity」用于衡量算法占用内存空间随着数据量变大时的增长趋势。这个概念与时间复杂度非常类似只需将“运行时间”替换为“占用内存空间”。
## 2.3.1   算法相关空间
算法运行过程中使用的内存空间主要包括以下几种
算法运行过程中使用的内存空间主要包括以下几种
- **输入空间**:用于存储算法的输入数据。
- **暂存空间**:用于存储算法运行过程中的变量、对象、函数上下文等数据。
- **暂存空间**:用于存储算法运行过程中的变量、对象、函数上下文等数据。
- **输出空间**:用于存储算法的输出数据。
一般情况下,空间复杂度的统计范围是“暂存空间”加上“输出空间”。
暂存空间可以进一步划分为三个部分
暂存空间可以进一步划分为三个部分
- **暂存数据**:用于保存算法运行过程中的各种常量、变量、对象等。
- **栈帧空间**:用于保存调用函数的上下文数据。系统在每次调用函数时都会在栈顶部创建一个栈帧,函数返回后,栈帧空间会被释放。
- **指令空间**:用于保存编译后的程序指令,在实际统计中通常忽略不计。
因此在分析一段程序的空间复杂度时,**我们通常统计暂存数据、输出数据、栈帧空间三部分**。
在分析一段程序的空间复杂度时,**我们通常统计暂存数据、栈帧空间和输出数据三部分**。
![算法使用的相关空间](space_complexity.assets/space_types.png)
@@ -294,7 +294,7 @@ comments: true
## 2.3.2   推算方法
空间复杂度的推算方法与时间复杂度大致相同,只需将统计对象从“计算操作数量”转为“使用空间大小”。
空间复杂度的推算方法与时间复杂度大致相同,只需将统计对象从“操作数量”转为“使用空间大小”。
而与时间复杂度不同的是,**我们通常只关注「最差空间复杂度」**。这是因为内存空间是一项硬性要求,我们必须确保在所有输入数据下都有足够的内存空间预留。
@@ -432,7 +432,7 @@ comments: true
```
**在递归函数中,需要注意统计栈帧空间**。例如以下代码:
**在递归函数中,需要注意统计栈帧空间**。例如以下代码
- 函数 `loop()` 在循环中调用了 $n$ 次 `function()` ,每轮中的 `function()` 都返回并释放了栈帧空间,因此空间复杂度仍为 $O(1)$ 。
- 递归函数 `recur()` 在运行过程中会同时存在 $n$ 个未返回的 `recur()` ,从而占用 $O(n)$ 的栈帧空间。
@@ -658,7 +658,7 @@ comments: true
## 2.3.3   常见类型
设输入数据大小为 $n$ ,常见的空间复杂度类型(从低到高排列)
设输入数据大小为 $n$ 下图展示了常见的空间复杂度类型(从低到高排列)
$$
\begin{aligned}
@@ -667,19 +667,19 @@ O(1) < O(\log n) < O(n) < O(n^2) < O(2^n) \newline
\end{aligned}
$$
![空间复杂度的常见类型](space_complexity.assets/space_complexity_common_types.png)
![常见的空间复杂度类型](space_complexity.assets/space_complexity_common_types.png)
<p align="center"> 图:空间复杂度的常见类型 </p>
<p align="center"> 图:常见的空间复杂度类型 </p>
!!! tip
部分示例代码需要一些前置知识,包括数组、链表、二叉树、递归算法等。如果你遇到看不懂的地方,可以在学完后面章节后再来复习。
部分示例代码需要一些前置知识,包括数组、链表、二叉树、递归算法等。如果你遇到看不懂的地方,可以在学完后面章节后再来复习。
### 1. &nbsp; 常数阶 $O(1)$
常数阶常见于数量与输入数据大小 $n$ 无关的常量、变量、对象。
需要注意的是,在循环中初始化变量或调用函数而占用的内存,在进入下一循环后就会被释放,即不会累积占用空间,空间复杂度仍为 $O(1)$
需要注意的是,在循环中初始化变量或调用函数而占用的内存,在进入下一循环后就会被释放,即不会累积占用空间,空间复杂度仍为 $O(1)$
=== "Java"
@@ -1010,7 +1010,7 @@ $$
### 2. &nbsp; 线性阶 $O(n)$
线性阶常见于元素数量与 $n$ 成正比的数组、链表、栈、队列等
线性阶常见于元素数量与 $n$ 成正比的数组、链表、栈、队列等
=== "Java"
@@ -1274,7 +1274,7 @@ $$
}
```
以下递归函数会同时存在 $n$ 个未返回的 `algorithm()` 函数,使用 $O(n)$ 大小的栈帧空间
以下递归函数会同时存在 $n$ 个未返回的 `algorithm()` 函数,使用 $O(n)$ 大小的栈帧空间
=== "Java"
@@ -1421,7 +1421,7 @@ $$
### 3. &nbsp; 平方阶 $O(n^2)$
平方阶常见于矩阵和图,元素数量与 $n$ 成平方关系
平方阶常见于矩阵和图,元素数量与 $n$ 成平方关系
=== "Java"
@@ -1800,7 +1800,7 @@ $$
### 4. &nbsp; 指数阶 $O(2^n)$
指数阶常见于二叉树。高度为 $n$ 的「满二叉树」的节点数量为 $2^n - 1$ ,占用 $O(2^n)$ 空间
指数阶常见于二叉树。高度为 $n$ 的「满二叉树」的节点数量为 $2^n - 1$ ,占用 $O(2^n)$ 空间
=== "Java"
@@ -1974,9 +1974,9 @@ $$
对数阶常见于分治算法和数据类型转换等。
例如归并排序算法,输入长度为 $n$ 的数组,每轮递归将数组从中点划分为两半,形成高度为 $\log n$ 的递归树,使用 $O(\log n)$ 栈帧空间。
例如归并排序算法,输入长度为 $n$ 的数组,每轮递归将数组从中点划分为两半,形成高度为 $\log n$ 的递归树,使用 $O(\log n)$ 栈帧空间。
再例如数字转化为字符串,输入任意正整数 $n$ ,它的位数为 $\log_{10} n$ ,即对应字符串长度为 $\log_{10} n$ ,因此空间复杂度为 $O(\log_{10} n) = O(\log n)$ 。
再例如数字转化为字符串,输入任意正整数 $n$ ,它的位数为 $\log_{10} n + 1$ ,即对应字符串长度为 $\log_{10} n + 1$ ,因此空间复杂度为 $O(\log_{10} n + 1) = O(\log n)$ 。
## 2.3.4 &nbsp; 权衡时间与空间
@@ -1984,4 +1984,4 @@ $$
**降低时间复杂度通常需要以提升空间复杂度为代价,反之亦然**。我们将牺牲内存空间来提升算法运行速度的思路称为“以空间换时间”;反之,则称为“以时间换空间”。
选择哪种思路取决于我们更看重哪个方面。在大多数情况下,时间比空间更宝贵,因此以空间换时间通常是更常用的策略。当然,在数据量很大的情况下,控制空间复杂度也是非常重要的。
选择哪种思路取决于我们更看重哪个方面。在大多数情况下,时间比空间更宝贵,因此以空间换时间通常是更常用的策略。当然,在数据量很大的情况下,控制空间复杂度也是非常重要的。

View File

@@ -6,45 +6,45 @@ comments: true
**算法效率评估**
- 时间效率和空间效率是评价算法性能的两个关键维度
- 时间效率和空间效率是衡量算法优劣的两个主要评价指标
- 我们可以通过实际测试来评估算法效率,但难以消除测试环境的影响,且会耗费大量计算资源。
- 复杂度分析可以克服实际测试的弊端,分析结果适用于所有运行平台,并且能够揭示算法在不同数据规模下的效率。
**时间复杂度**
- 时间复杂度用于衡量算法运行时间随数据量增长的趋势,可以有效评估算法效率,但在某些情况下可能失效,如在输入数据量较小或时间复杂度相同时,无法精确对比算法效率的优劣。
- 最差时间复杂度使用大 $O$ 符号表示,函数渐近上界,反映当 $n$ 趋向正无穷时,$T(n)$ 的增长级别。
- 推算时间复杂度分为两步,首先统计计算操作数量,然后判断渐近上界。
- 常见时间复杂度从小到大排列有 $O(1)$ , $O(\log n)$ , $O(n)$ , $O(n \log n)$ , $O(n^2)$ , $O(2^n)$ , $O(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^2)$ , $O(2^n)$ 等。
- 常见空间复杂度从小到大排列有 $O(1)$ $O(\log n)$ $O(n)$ $O(n^2)$ $O(2^n)$ 等。
## 2.4.1 &nbsp; Q & A
!!! question "尾递归的空间复杂度是 $O(1)$ 吗?"
理论上,尾递归函数的空间复杂度可以被优化至 $O(1)$ 。不过绝大多数编程语言(例如 Java, Python, C++, Go, C# 等)都不支持自动优化尾递归,因此通常认为空间复杂度是 $O(n)$ 。
理论上,尾递归函数的空间复杂度可以被优化至 $O(1)$ 。不过绝大多数编程语言(例如 Java Python C++ 、Go 、C# 等)都不支持自动优化尾递归,因此通常认为空间复杂度是 $O(n)$ 。
!!! question "函数和方法这两个术语的区别是什么?"
函数function可以独立执行所有参数都以显式传递。方法method与一个对象关联方法被隐式传递给调用它的对象,方法能够对类的实例中包含的数据进行操作。
函数function可以独立执行所有参数都以显式传递。方法method与一个对象关联被隐式传递给调用它的对象能够对类的实例中包含的数据进行操作。
以几个常见的编程语言为例:
下面以几个常见的编程语言来说明。
- C 语言是过程式编程语言没有面向对象的概念所以只有函数。但我们可以通过创建结构struct来模拟面向对象编程与结构体相关联的函数就相当于其他语言中的方法。
- Java, C# 是面向对象的编程语言,代码块(方法)通常都是作为某个类的一部分。静态方法的行为类似于函数,因为它被绑定在类上,不能访问特定的实例变量。
- C++, Python 既支持过程式编程(函数)也支持面向对象编程(方法)。
- C 语言是过程式编程语言,没有面向对象的概念,所以只有函数。但我们可以通过创建结构struct来模拟面向对象编程与结构体相关联的函数就相当于其他语言中的方法。
- Java C# 是面向对象的编程语言,代码块(方法)通常都是作为某个类的一部分。静态方法的行为类似于函数,因为它被绑定在类上,不能访问特定的实例变量。
- C++ Python 既支持过程式编程(函数)也支持面向对象编程(方法)。
!!! question "图“空间复杂度的常见类型”反映的是否是占用空间的绝对大小?"
!!! question "图“空间复杂度的常见类型”反映的是否是占用空间的绝对大小?"
不是,该图片展示的是空间复杂度,其反映的是增长趋势,而不是占用空间的绝对大小。
不是,该图片展示的是空间复杂度,其反映的是增长趋势,而不是占用空间的绝对大小。
假设取 $n = 8$ ,你可能会发现每条曲线的值与函数对应不上。这是因为每条曲线都包含一个常数项,用于将取值范围压缩到一个视觉舒适的范围内。

View File

@@ -7,14 +7,10 @@ comments: true
运行时间可以直观且准确地反映算法的效率。如果我们想要准确预估一段代码的运行时间,应该如何操作呢?
1. **确定运行平台**,包括硬件配置、编程语言、系统环境等,这些因素都会影响代码的运行效率。
2. **评估各种计算操作所需的运行时间**,例如加法操作 `+` 需要 1 ns乘法操作 `*` 需要 10 ns打印操作需要 5 ns 等。
2. **评估各种计算操作所需的运行时间**,例如加法操作 `+` 需要 1 ns乘法操作 `*` 需要 10 ns打印操作 `print()` 需要 5 ns 等。
3. **统计代码中所有的计算操作**,并将所有操作的执行时间求和,从而得到运行时间。
例如以下代码,输入数据大小为 $n$ 。根据以上方法,可以得到算法运行时间为 $6n + 12$ ns 。
$$
1 + 1 + 10 + (1 + 5) \times n = 6n + 12
$$
例如以下代码,输入数据大小为 $n$
=== "Java"
@@ -185,28 +181,34 @@ $$
}
```
但实际上,**统计算法的运行时间既不合理也不现实**。首先,我们不希望预估时间和运行平台绑定,因为算法需要在各种不同的平台上运行。其次,我们很难获知每种操作的运行时间,这给预估过程带来了极大的难度。
根据以上方法,可以得到算法运行时间为 $6n + 12$ ns
$$
1 + 1 + 10 + (1 + 5) \times n = 6n + 12
$$
但实际上,**统计算法的运行时间既不合理也不现实**。首先,我们不希望将预估时间和运行平台绑定,因为算法需要在各种不同的平台上运行。其次,我们很难获知每种操作的运行时间,这给预估过程带来了极大的难度。
## 2.2.1 &nbsp; 统计时间增长趋势
「时间复杂度分析」采取了一种不同的方法,其统计的不是算法运行时间,**而是算法运行时间随着数据量变大时的增长趋势**。
“时间增长趋势”这个概念比较抽象,我们通过一个例子来加以理解。假设输入数据大小为 $n$ ,给定三个算法函数 `A` , `B` , `C`
“时间增长趋势”这个概念比较抽象,我们通过一个例子来加以理解。假设输入数据大小为 $n$ ,给定三个算法函数 `A` `B` `C`
=== "Java"
```java title=""
// 算法 A 时间复杂度:常数阶
// 算法 A 时间复杂度:常数阶
void algorithm_A(int n) {
System.out.println(0);
}
// 算法 B 时间复杂度:线性阶
// 算法 B 时间复杂度:线性阶
void algorithm_B(int n) {
for (int i = 0; i < n; i++) {
System.out.println(0);
}
}
// 算法 C 时间复杂度:常数阶
// 算法 C 时间复杂度:常数阶
void algorithm_C(int n) {
for (int i = 0; i < 1000000; i++) {
System.out.println(0);
@@ -217,17 +219,17 @@ $$
=== "C++"
```cpp title=""
// 算法 A 时间复杂度:常数阶
// 算法 A 时间复杂度:常数阶
void algorithm_A(int n) {
cout << 0 << endl;
}
// 算法 B 时间复杂度:线性阶
// 算法 B 时间复杂度:线性阶
void algorithm_B(int n) {
for (int i = 0; i < n; i++) {
cout << 0 << endl;
}
}
// 算法 C 时间复杂度:常数阶
// 算法 C 时间复杂度:常数阶
void algorithm_C(int n) {
for (int i = 0; i < 1000000; i++) {
cout << 0 << endl;
@@ -238,14 +240,14 @@ $$
=== "Python"
```python title=""
# 算法 A 时间复杂度:常数阶
# 算法 A 时间复杂度:常数阶
def algorithm_A(n: int):
print(0)
# 算法 B 时间复杂度:线性阶
# 算法 B 时间复杂度:线性阶
def algorithm_B(n: int):
for _ in range(n):
print(0)
# 算法 C 时间复杂度:常数阶
# 算法 C 时间复杂度:常数阶
def algorithm_C(n: int):
for _ in range(1000000):
print(0)
@@ -254,17 +256,17 @@ $$
=== "Go"
```go title=""
// 算法 A 时间复杂度:常数阶
// 算法 A 时间复杂度:常数阶
func algorithm_A(n int) {
fmt.Println(0)
}
// 算法 B 时间复杂度:线性阶
// 算法 B 时间复杂度:线性阶
func algorithm_B(n int) {
for i := 0; i < n; i++ {
fmt.Println(0)
}
}
// 算法 C 时间复杂度:常数阶
// 算法 C 时间复杂度:常数阶
func algorithm_C(n int) {
for i := 0; i < 1000000; i++ {
fmt.Println(0)
@@ -275,17 +277,17 @@ $$
=== "JS"
```javascript title=""
// 算法 A 时间复杂度:常数阶
// 算法 A 时间复杂度:常数阶
function algorithm_A(n) {
console.log(0);
}
// 算法 B 时间复杂度:线性阶
// 算法 B 时间复杂度:线性阶
function algorithm_B(n) {
for (let i = 0; i < n; i++) {
console.log(0);
}
}
// 算法 C 时间复杂度:常数阶
// 算法 C 时间复杂度:常数阶
function algorithm_C(n) {
for (let i = 0; i < 1000000; i++) {
console.log(0);
@@ -297,17 +299,17 @@ $$
=== "TS"
```typescript title=""
// 算法 A 时间复杂度:常数阶
// 算法 A 时间复杂度:常数阶
function algorithm_A(n: number): void {
console.log(0);
}
// 算法 B 时间复杂度:线性阶
// 算法 B 时间复杂度:线性阶
function algorithm_B(n: number): void {
for (let i = 0; i < n; i++) {
console.log(0);
}
}
// 算法 C 时间复杂度:常数阶
// 算法 C 时间复杂度:常数阶
function algorithm_C(n: number): void {
for (let i = 0; i < 1000000; i++) {
console.log(0);
@@ -318,17 +320,17 @@ $$
=== "C"
```c title=""
// 算法 A 时间复杂度:常数阶
// 算法 A 时间复杂度:常数阶
void algorithm_A(int n) {
printf("%d", 0);
}
// 算法 B 时间复杂度:线性阶
// 算法 B 时间复杂度:线性阶
void algorithm_B(int n) {
for (int i = 0; i < n; i++) {
printf("%d", 0);
}
}
// 算法 C 时间复杂度:常数阶
// 算法 C 时间复杂度:常数阶
void algorithm_C(int n) {
for (int i = 0; i < 1000000; i++) {
printf("%d", 0);
@@ -339,17 +341,17 @@ $$
=== "C#"
```csharp title=""
// 算法 A 时间复杂度:常数阶
// 算法 A 时间复杂度:常数阶
void algorithm_A(int n) {
Console.WriteLine(0);
}
// 算法 B 时间复杂度:线性阶
// 算法 B 时间复杂度:线性阶
void algorithm_B(int n) {
for (int i = 0; i < n; i++) {
Console.WriteLine(0);
}
}
// 算法 C 时间复杂度:常数阶
// 算法 C 时间复杂度:常数阶
void algorithm_C(int n) {
for (int i = 0; i < 1000000; i++) {
Console.WriteLine(0);
@@ -360,19 +362,19 @@ $$
=== "Swift"
```swift title=""
// 算法 A 时间复杂度:常数阶
// 算法 A 时间复杂度:常数阶
func algorithmA(n: Int) {
print(0)
}
// 算法 B 时间复杂度:线性阶
// 算法 B 时间复杂度:线性阶
func algorithmB(n: Int) {
for _ in 0 ..< n {
print(0)
}
}
// 算法 C 时间复杂度:常数阶
// 算法 C 时间复杂度:常数阶
func algorithmC(n: Int) {
for _ in 0 ..< 1000000 {
print(0)
@@ -389,17 +391,17 @@ $$
=== "Dart"
```dart title=""
// 算法 A 时间复杂度:常数阶
// 算法 A 时间复杂度:常数阶
void algorithmA(int n) {
print(0);
}
// 算法 B 时间复杂度:线性阶
// 算法 B 时间复杂度:线性阶
void algorithmB(int n) {
for (int i = 0; i < n; i++) {
print(0);
}
}
// 算法 C 时间复杂度:常数阶
// 算法 C 时间复杂度:常数阶
void algorithmC(int n) {
for (int i = 0; i < 1000000; i++) {
print(0);
@@ -410,17 +412,17 @@ $$
=== "Rust"
```rust title=""
// 算法 A 时间复杂度:常数阶
// 算法 A 时间复杂度:常数阶
fn algorithm_A(n: i32) {
println!("{}", 0);
}
// 算法 B 时间复杂度:线性阶
// 算法 B 时间复杂度:线性阶
fn algorithm_B(n: i32) {
for _ in 0..n {
println!("{}", 0);
}
}
// 算法 C 时间复杂度:常数阶
// 算法 C 时间复杂度:常数阶
fn algorithm_C(n: i32) {
for _ in 0..1000000 {
println!("{}", 0);
@@ -434,21 +436,19 @@ $$
算法 `C` 中的打印操作需要循环 $1000000$ 次,虽然运行时间很长,但它与输入数据大小 $n$ 无关。因此 `C` 的时间复杂度和 `A` 相同,仍为「常数阶」。
![算法 A, B, C 的时间增长趋势](time_complexity.assets/time_complexity_simple_example.png)
![算法 A 、B 和 C 的时间增长趋势](time_complexity.assets/time_complexity_simple_example.png)
<p align="center"> 图:算法 A, B, C 的时间增长趋势 </p>
<p align="center"> 图:算法 A 、B 和 C 的时间增长趋势 </p>
相较于直接统计算法运行时间,时间复杂度分析有哪些特点呢?
**时间复杂度能够有效评估算法效率**。例如,算法 `B` 的运行时间呈线性增长,在 $n > 1$ 时比算法 `A` 更慢,在 $n > 1000000$ 时比算法 `C` 更慢。事实上,只要输入数据大小 $n$ 足够大,复杂度为“常数阶”的算法一定优于“线性阶”的算法,这正是时间增长趋势所表达的含义。
**时间复杂度的推算方法更简便**。显然,运行平台和计算操作类型都与算法运行时间的增长趋势无关。因此在时间复杂度分析中,我们可以简单地将所有计算操作的执行时间视为相同的“单位时间”,从而将“计算操作的运行时间的统计”简化为“计算操作的数量的统计”,这样以来估算难度就大大降低了
**时间复杂度也存在一定的局限性**。例如,尽管算法 `A` 和 `C` 的时间复杂度相同,但实际运行时间差别很大。同样,尽管算法 `B` 的时间复杂度比 `C` 高,但在输入数据大小 $n$ 较小时,算法 `B` 明显优于算法 `C` 。在这些情况下,我们很难仅凭时间复杂度判断算法效率高低。当然,尽管存在上述问题,复杂度分析仍然是评判算法效率最有效且常用的方法。
- **时间复杂度能够有效评估算法效率**。例如,算法 `B` 的运行时间呈线性增长,在 $n > 1$ 时比算法 `A` 更慢,在 $n > 1000000$ 时比算法 `C` 更慢。事实上,只要输入数据大小 $n$ 足够大,复杂度为“常数阶”的算法一定优于“线性阶”的算法,这正是时间增长趋势所表达的含义。
- **时间复杂度的推算方法更简便**。显然,运行平台和计算操作类型都与算法运行时间的增长趋势无关。因此在时间复杂度分析中,我们可以简单地将所有计算操作的执行时间视为相同的“单位时间”,从而将“计算操作的运行时间的统计”简化为“计算操作的数量的统计”,这样以来估算难度就大大降低了。
- **时间复杂度也存在一定的局限性**。例如,尽管算法 `A` 和 `C` 的时间复杂度相同,但实际运行时间差别很大。同样,尽管算法 `B` 的时间复杂度比 `C` 高,但在输入数据大小 $n$ 较小时,算法 `B` 明显优于算法 `C` 。在这些情况下,我们很难仅凭时间复杂度判断算法效率的高低。当然,尽管存在上述问题,复杂度分析仍然是评判算法效率最有效且常用的方法
## 2.2.2 &nbsp; 函数渐近上界
给定一个函数 `algorithm()`
给定一个输入大小为 $n$ 的函数
=== "Java"
@@ -609,15 +609,15 @@ $$
}
```
设算法的计算操作数量是一个关于输入数据大小 $n$ 的函数,记为 $T(n)$ ,则以上函数的的操作数量为:
设算法的操作数量是一个关于输入数据大小 $n$ 的函数,记为 $T(n)$ ,则以上函数的的操作数量为:
$$
T(n) = 3 + 2n
$$
$T(n)$ 是一次函数,说明时间的增长趋势是线性的,因此时间复杂度是线性阶。
$T(n)$ 是一次函数,说明其运行时间的增长趋势是线性的,因此它的时间复杂度是线性阶。
我们将线性阶的时间复杂度记为 $O(n)$ ,这个数学符号称为「大 $O$ 记号 Big-$O$ Notation」表示函数 $T(n)$ 的「渐近上界 Asymptotic Upper Bound」。
我们将线性阶的时间复杂度记为 $O(n)$ ,这个数学符号称为「大 $O$ 记号 big-$O$ notation」表示函数 $T(n)$ 的「渐近上界 asymptotic upper bound」。
时间复杂度分析本质上是计算“操作数量函数 $T(n)$”的渐近上界。接下来,我们来看函数渐近上界的数学定义。
@@ -632,27 +632,27 @@ $T(n)$ 是一次函数,说明时间的增长趋势是线性的,因此其时
T(n) = O(f(n))
$$
如下图所示,计算渐近上界就是寻找一个函数 $f(n)$ ,使得当 $n$ 趋向于无穷大时,$T(n)$ 和 $f(n)$ 处于相同的增长级别,仅相差一个常数项 $c$ 的倍数。
![函数的渐近上界](time_complexity.assets/asymptotic_upper_bound.png)
<p align="center"> 图:函数的渐近上界 </p>
也就是说,计算渐近上界就是寻找一个函数 $f(n)$ ,使得当 $n$ 趋向于无穷大时,$T(n)$ 和 $f(n)$ 处于相同的增长级别,仅相差一个常数项 $c$ 的倍数。
## 2.2.3 &nbsp; 推算方法
渐近上界的数学味儿有点重,如果你感觉没有完全理解,也无担心。因为在实际使用中,我们只需要掌握推算方法,数学意义可以逐渐领悟。
渐近上界的数学味儿有点重,如果你感觉没有完全理解,也无担心。因为在实际使用中,我们只需要掌握推算方法,数学意义可以逐渐领悟。
根据定义,确定 $f(n)$ 之后,我们便可得到时间复杂度 $O(f(n))$ 。那么如何确定渐近上界 $f(n)$ 呢?总体分为两步:首先统计操作数量,然后判断渐近上界。
### 1. &nbsp; 第一步:统计操作数量
针对代码,逐行从上到下计算即可。然而,由于上述 $c \cdot f(n)$ 中的常数项 $c$ 可以取任意大小,**因此操作数量 $T(n)$ 中的各种系数、常数项都可以被忽略**。根据此原则,可以总结出以下计数简化技巧
针对代码,逐行从上到下计算即可。然而,由于上述 $c \cdot f(n)$ 中的常数项 $c$ 可以取任意大小,**因此操作数量 $T(n)$ 中的各种系数、常数项都可以被忽略**。根据此原则,可以总结出以下计数简化技巧
1. **忽略 $T(n)$ 中的常数项**。因为它们都与 $n$ 无关,所以对时间复杂度不产生影响。
2. **省略所有系数**。例如,循环 $2n$ 次、$5n + 1$ 次等,都可以简化记为 $n$ 次,因为 $n$ 前面的系数对时间复杂度没有影响。
3. **循环嵌套时使用乘法**。总操作数量等于外层循环和内层循环操作数量之积,每一层循环依然可以分别套用上述 `1.` 和 `2.` 技巧。
以下示例展示了使用上述技巧前后的统计结果。两者推出的时间复杂度相同,为 $O(n^2)$ 。
以下代码与公式分别展示了使用上述技巧前后的统计结果。两者推出的时间复杂度相同,为 $O(n^2)$ 。
$$
\begin{aligned}
@@ -880,7 +880,8 @@ $$
**时间复杂度由多项式 $T(n)$ 中最高阶的项来决定**。这是因为在 $n$ 趋于无穷大时,最高阶的项将发挥主导作用,其他项的影响都可以被忽略。
以下表格展示了一些例子,其中一些夸张的值是为了强调“系数无法撼动阶数”这一结论。当 $n$ 趋于无穷大时,这些常数变得无足轻重。
<p align="center"> 表:多项式时间复杂度示例 </p>
<p align="center"> 表:不同操作数量对应的时间复杂度 </p>
<div class="center-table" markdown>
@@ -905,19 +906,19 @@ O(1) < O(\log n) < O(n) < O(n \log n) < O(n^2) < O(2^n) < O(n!) \newline
\end{aligned}
$$
![时间复杂度的常见类型](time_complexity.assets/time_complexity_common_types.png)
![常见的时间复杂度类型](time_complexity.assets/time_complexity_common_types.png)
<p align="center"> 图:时间复杂度的常见类型 </p>
<p align="center"> 图:常见的时间复杂度类型 </p>
!!! tip
部分示例代码需要一些预备知识,包括数组、递归等。如果你遇到不理解的部分,可以在学完后面章节后再回顾。现阶段,请先专注于理解时间复杂度的含义和推算方法。
部分示例代码需要一些预备知识,包括数组、递归等。如果你遇到不理解的部分,可以在学完后面章节后再回顾。现阶段,请先专注于理解时间复杂度的含义和推算方法。
### 1. &nbsp; 常数阶 $O(1)$
常数阶的操作数量与输入数据大小 $n$ 无关,即不随着 $n$ 的变化而变化。
对于以下算法,尽管操作数量 `size` 可能很大,但由于其与数据大小 $n$ 无关,因此时间复杂度仍为 $O(1)$
对于以下算法,尽管操作数量 `size` 可能很大,但由于其与输入数据大小 $n$ 无关,因此时间复杂度仍为 $O(1)$
=== "Java"
@@ -1084,7 +1085,7 @@ $$
### 2. &nbsp; 线性阶 $O(n)$
线性阶的操作数量相对于输入数据大小以线性级别增长。线性阶通常出现在单层循环中
线性阶的操作数量相对于输入数据大小 $n$ 以线性级别增长。线性阶通常出现在单层循环中
=== "Java"
@@ -1234,7 +1235,7 @@ $$
}
```
遍历数组和遍历链表等操作的时间复杂度均为 $O(n)$ ,其中 $n$ 为数组或链表的长度
遍历数组和遍历链表等操作的时间复杂度均为 $O(n)$ ,其中 $n$ 为数组或链表的长度
=== "Java"
@@ -1402,11 +1403,11 @@ $$
}
```
值得注意的是,**数据大小 $n$ 需根据输入数据的类型来具体确定**。比如在第一个示例中,变量 $n$ 为输入数据大小;在第二个示例中,数组长度 $n$ 为数据大小。
值得注意的是,**输入数据大小 $n$ 需根据输入数据的类型来具体确定**。比如在第一个示例中,变量 $n$ 为输入数据大小;在第二个示例中,数组长度 $n$ 为数据大小。
### 3. &nbsp; 平方阶 $O(n^2)$
平方阶的操作数量相对于输入数据大小以平方级别增长。平方阶通常出现在嵌套循环中,外层循环和内层循环都为 $O(n)$ ,因此总体为 $O(n^2)$
平方阶的操作数量相对于输入数据大小以平方级别增长。平方阶通常出现在嵌套循环中,外层循环和内层循环都为 $O(n)$ ,因此总体为 $O(n^2)$
=== "Java"
@@ -1599,11 +1600,13 @@ $$
}
```
![常数阶、线性阶平方阶时间复杂度](time_complexity.assets/time_complexity_constant_linear_quadratic.png)
下图对比了常数阶、线性阶平方阶三种时间复杂度
<p align="center"> 图:常数阶、线性阶平方阶的时间复杂度 </p>
![常数阶、线性阶平方阶的时间复杂度](time_complexity.assets/time_complexity_constant_linear_quadratic.png)
以「冒泡排序」为例,外层循环执行 $n - 1$ 次,内层循环执行 $n-1, n-2, \cdots, 2, 1$ 次,平均为 $\frac{n}{2}$ 次,因此时间复杂度为 $O(n^2)$ 。
<p align="center"> 图:常数阶、线性阶和平方阶的时间复杂度 </p>
以冒泡排序为例,外层循环执行 $n - 1$ 次,内层循环执行 $n-1, n-2, \cdots, 2, 1$ 次,平均为 $\frac{n}{2}$ 次,因此时间复杂度为 $O(n^2)$
$$
O((n - 1) \frac{n}{2}) = O(n^2)
@@ -1883,9 +1886,7 @@ $$
### 4. &nbsp; 指数阶 $O(2^n)$
生物学的“细胞分裂”是指数阶增长的典型例子:初始状态为 $1$ 个细胞,分裂一轮后变为 $2$ 个,分裂两轮后变为 $4$ 个,以此类推,分裂 $n$ 轮后有 $2^n$ 个细胞。
以下代码模拟了细胞分裂的过程。
生物学的“细胞分裂”是指数阶增长的典型例子:初始状态为 $1$ 个细胞,分裂一轮后变为 $2$ 个,分裂两轮后变为 $4$ 个,以此类推,分裂 $n$ 轮后有 $2^n$ 个细胞。相关代码如下:
=== "Java"
@@ -2109,11 +2110,13 @@ $$
}
```
下图展示了细胞分裂的过程。
![指数阶的时间复杂度](time_complexity.assets/time_complexity_exponential.png)
<p align="center"> 图:指数阶的时间复杂度 </p>
在实际算法中,指数阶常出现于递归函数。例如以下代码,其递归地一分为二,经过 $n$ 次分裂后停止
在实际算法中,指数阶常出现于递归函数。例如以下代码,其递归地一分为二,经过 $n$ 次分裂后停止
=== "Java"
@@ -2248,7 +2251,7 @@ $$
### 5. &nbsp; 对数阶 $O(\log n)$
与指数阶相反,对数阶反映了“每轮缩减到一半”的情况。设输入数据大小为 $n$ ,由于每轮缩减到一半,因此循环次数是 $\log_2 n$ ,即 $2^n$ 的反函数。
与指数阶相反,对数阶反映了“每轮缩减到一半”的情况。设输入数据大小为 $n$ ,由于每轮缩减到一半,因此循环次数是 $\log_2 n$ ,即 $2^n$ 的反函数。相关代码如下:
=== "Java"
@@ -2423,7 +2426,7 @@ $$
<p align="center"> 图:对数阶的时间复杂度 </p>
与指数阶类似,对数阶也常出现于递归函数。以下代码形成了一个高度为 $\log_2 n$ 的递归树
与指数阶类似,对数阶也常出现于递归函数。以下代码形成了一个高度为 $\log_2 n$ 的递归树
=== "Java"
@@ -2554,13 +2557,11 @@ $$
}
```
对数阶常出现于基于分治的算法中,体现了“一分为多”和“化繁为简”的算法思想。它增长缓慢,是理想的时间复杂度,仅次于常数阶。
对数阶常出现于基于分治策略的算法中,体现了“一分为多”和“化繁为简”的算法思想。它增长缓慢,是理想的时间复杂度,仅次于常数阶。
### 6. &nbsp; 线性对数阶 $O(n \log n)$
线性对数阶常出现于嵌套循环中,两层循环的时间复杂度分别为 $O(\log n)$ 和 $O(n)$ 。
主流排序算法的时间复杂度通常为 $O(n \log n)$ ,例如快速排序、归并排序、堆排序等。
线性对数阶常出现于嵌套循环中,两层循环的时间复杂度分别为 $O(\log n)$ 和 $O(n)$ 。相关代码如下:
=== "Java"
@@ -2748,6 +2749,8 @@ $$
<p align="center"> 图:线性对数阶的时间复杂度 </p>
主流排序算法的时间复杂度通常为 $O(n \log n)$ ,例如快速排序、归并排序、堆排序等。
### 7. &nbsp; 阶乘阶 $O(n!)$
阶乘阶对应数学上的“全排列”问题。给定 $n$ 个互不重复的元素,求其所有可能的排列方案,方案数量为:
@@ -2756,7 +2759,7 @@ $$
n! = n \times (n - 1) \times (n - 2) \times \cdots \times 2 \times 1
$$
阶乘通常使用递归实现。例如以下代码,第一层分裂出 $n$ 个,第二层分裂出 $n - 1$ 个,以此类推,直至第 $n$ 层时止分裂
阶乘通常使用递归实现。例如以下代码,第一层分裂出 $n$ 个,第二层分裂出 $n - 1$ 个,以此类推,直至第 $n$ 层时止分裂
=== "Java"
@@ -2950,16 +2953,16 @@ $$
<p align="center"> 图:阶乘阶的时间复杂度 </p>
请注意,因为 $n! > 2^n$ ,所以阶乘阶比指数阶增长更快,在 $n$ 较大时也是不可接受的。
请注意,因为 $n! > 2^n$ ,所以阶乘阶比指数阶增长更快,在 $n$ 较大时也是不可接受的。
## 2.2.5 &nbsp; 最差、最佳、平均时间复杂度
**算法的时间效率往往不是固定的,而是与输入数据的分布有关**。假设输入一个长度为 $n$ 的数组 `nums` ,其中 `nums` 由从 $1$ 至 $n$ 的数字组成,但元素顺序是随机打乱的,任务目标是返回元素 $1$ 的索引。我们可以得出以下结论
**算法的时间效率往往不是固定的,而是与输入数据的分布有关**。假设输入一个长度为 $n$ 的数组 `nums` ,其中 `nums` 由从 $1$ 至 $n$ 的数字组成,每个数字只出现一次,但元素顺序是随机打乱的,任务目标是返回元素 $1$ 的索引。我们可以得出以下结论
- 当 `nums = [?, ?, ..., 1]` ,即当末尾元素是 $1$ 时,需要完整遍历数组,**达到最差时间复杂度 $O(n)$** 。
- 当 `nums = [1, ?, ?, ...]` ,即当首个数字为 $1$ 时,无论数组多长都不需要继续遍历,**达到最佳时间复杂度 $\Omega(1)$** 。
- 当 `nums = [1, ?, ?, ...]` ,即当首个元素为 $1$ 时,无论数组多长都不需要继续遍历,**达到最佳时间复杂度 $\Omega(1)$** 。
「最差时间复杂度」对应函数渐近上界,使用大 $O$ 记号表示。相应地,「最佳时间复杂度」对应函数渐近下界,用 $\Omega$ 记号表示
「最差时间复杂度」对应函数渐近上界,使用大 $O$ 记号表示。相应地,「最佳时间复杂度」对应函数渐近下界,用 $\Omega$ 记号表示
=== "Java"
@@ -3315,10 +3318,10 @@ $$
从上述示例可以看出,最差或最佳时间复杂度只出现于“特殊的数据分布”,这些情况的出现概率可能很小,并不能真实地反映算法运行效率。相比之下,**「平均时间复杂度」可以体现算法在随机输入数据下的运行效率**,用 $\Theta$ 记号来表示。
对于部分算法,我们可以简单地推算出随机数据分布下的平均情况。比如上述示例,由于输入数组是被打乱的,因此元素 $1$ 出现在任意索引的概率都是相等的,那么算法的平均循环次数是数组长度的一半 $\frac{n}{2}$ ,平均时间复杂度为 $\Theta(\frac{n}{2}) = \Theta(n)$ 。
对于部分算法,我们可以简单地推算出随机数据分布下的平均情况。比如上述示例,由于输入数组是被打乱的,因此元素 $1$ 出现在任意索引的概率都是相等的,那么算法的平均循环次数是数组长度的一半 $\frac{n}{2}$ ,平均时间复杂度为 $\Theta(\frac{n}{2}) = \Theta(n)$ 。
但对于较为复杂的算法,计算平均时间复杂度往往是比较困难的,因为很难分析出在数据分布下的整体数学期望。在这种情况下,我们通常使用最差时间复杂度作为算法效率的评判标准。
!!! question "为什么很少看到 $\Theta$ 符号?"
可能由于 $O$ 符号过于朗朗上口,我们常常使用它来表示平均复杂度」,但从严格意义上看,这种做法并不规范。在本书和其他资料中,若遇到类似“平均时间复杂度 $O(n)$”的表述,请将其直接理解为 $\Theta(n)$ 。
可能由于 $O$ 符号过于朗朗上口,我们常常使用它来表示平均时间复杂度但从严格意义上看,这种做法并不规范。在本书和其他资料中,若遇到类似“平均时间复杂度 $O(n)$”的表述,请将其直接理解为 $\Theta(n)$ 。