xinyin025/hello-algo
1
0
Fork 0
mirror of https://github.com/krahets/hello-algo.git synced 2026-07-10 06:26:08 +00:00
Code Issues Packages Projects Releases Wiki Activity

build

Browse Source
This commit is contained in:
krahets
2023-08-08 23:15:13 +08:00
parent 48adefba25
commit 6d41b5da04
11 changed files with 350 additions and 150 deletions
Download Patch File Download Diff File Expand all files Collapse all files
chapter_computational_complexity/time_complexity.md
+114 -70
View File
@@ -4,15 +4,13 @@ comments: true
# 2.2.   时间复杂度
## 2.2.1.   统计算法运行时间
运行时间可以直观且准确地反映算法的效率。然而，如果我们想要准确预估一段代码的运行时间，应该如何操作呢？
运行时间可以直观且准确地反映算法的效率。如果我们想要准确预估一段代码的运行时间，应该如何操作呢？
1. **确定运行平台**，包括硬件配置、编程语言、系统环境等，这些因素都会影响代码的运行效率。
2. **评估各种计算操作所需的运行时间**，例如加法操作 `+` 需要 1 ns，乘法操作 `*` 需要 10 ns，打印操作需要 5 ns 等。
3. **统计代码中所有的计算操作**，并将所有操作的执行时间求和，从而得到运行时间。
例如以下代码，输入数据大小为 $n$ ，根据以上方法，可以得到算法运行时间为 $6n + 12$ ns 。
例如以下代码，输入数据大小为 $n$ 。根据以上方法，可以得到算法运行时间为 $6n + 12$ ns 。
$$
1 + 1 + 10 + (1 + 5) \times n = 6n + 12
@@ -175,20 +173,25 @@ $$
=== "Rust"
```rust title=""
// 在某运行平台下
fn algorithm(n: i32) {
let mut a = 2; // 1 ns
a = a + 1; // 1 ns
a = a * 2; // 10 ns
// 循环 n 次
for _ in 0..n { // 1 ns ，每轮都要执行 i++
println!("{}", 0); // 5 ns
}
}
```
然而实际上，**统计算法的运行时间既不合理也不现实**。首先，我们不希望预估时间和运行平台绑定，因为算法需要在各种不同的平台上运行。其次，我们很难获知每种操作的运行时间，这给预估过程带来了极大的难度。
但实际上，**统计算法的运行时间既不合理也不现实**。首先，我们不希望预估时间和运行平台绑定，因为算法需要在各种不同的平台上运行。其次，我们很难获知每种操作的运行时间，这给预估过程带来了极大的难度。
## 2.2.2.   统计时间增长趋势
## 2.2.1.   统计时间增长趋势
「时间复杂度分析」采取了一种不同的方法，其统计的不是算法运行时间，**而是算法运行时间随着数据量变大时的增长趋势**。
“时间增长趋势”这个概念较为抽象，我们通过一个例子来加以理解。假设输入数据大小为 $n$ ，给定三个算法 `A` , `B` , `C` 。
- 算法 `A` 只有 $1$ 个打印操作，算法运行时间不随着 $n$ 增大而增长。我们称此算法的时间复杂度为「常数阶」。
- 算法 `B` 中的打印操作需要循环 $n$ 次，算法运行时间随着 $n$ 增大呈线性增长。此算法的时间复杂度被称为「线性阶」。
- 算法 `C` 中的打印操作需要循环 $1000000$ 次，但运行时间仍与输入数据大小 $n$ 无关。因此 `C` 的时间复杂度和 `A` 相同，仍为「常数阶」。
“时间增长趋势”这个概念比较抽象，我们通过一个例子来加以理解。假设输入数据大小为 $n$ ，给定三个算法函数 `A` , `B` , `C` 。
=== "Java"
@@ -407,28 +410,45 @@ $$
=== "Rust"
```rust title=""
// 算法 A 时间复杂度：常数阶
fn algorithm_A(n: i32) {
println!("{}", 0);
}
// 算法 B 时间复杂度：线性阶
fn algorithm_B(n: i32) {
for _ in 0..n {
println!("{}", 0);
}
}
// 算法 C 时间复杂度：常数阶
fn algorithm_C(n: i32) {
for _ in 0..1000000 {
println!("{}", 0);
}
}
```
算法 `A` 只有 $1$ 个打印操作，算法运行时间不随着 $n$ 增大而增长。我们称此算法的时间复杂度为「常数阶」。
算法 `B` 中的打印操作需要循环 $n$ 次，算法运行时间随着 $n$ 增大呈线性增长。此算法的时间复杂度被称为「线性阶」。
算法 `C` 中的打印操作需要循环 $1000000$ 次，虽然运行时间很长，但它与输入数据大小 $n$ 无关。因此 `C` 的时间复杂度和 `A` 相同，仍为「常数阶」。
![算法 A, B, C 的时间增长趋势](time_complexity.assets/time_complexity_simple_example.png)
<p align="center"> Fig. 算法 A, B, C 的时间增长趋势 </p>
相较于直接统计算法运行时间，时间复杂度分析有哪些优势和局限性呢？
相较于直接统计算法运行时间，时间复杂度分析有哪些特点呢？
**时间复杂度能够有效评估算法效率**。例如，算法 `B` 的运行时间呈线性增长，在 $n > 1$ 时比算法 `A` 慢，在 $n > 1000000$ 时比算法 `C` 慢。事实上，只要输入数据大小 $n$ 足够大，复杂度为「常数阶」的算法一定优于「线性阶」的算法，这正是时间增长趋势所表达的含义。
**时间复杂度能够有效评估算法效率**。例如，算法 `B` 的运行时间呈线性增长，在 $n > 1$ 时比算法 `A` 更慢，在 $n > 1000000$ 时比算法 `C` 更慢。事实上，只要输入数据大小 $n$ 足够大，复杂度为“常数阶”的算法一定优于“线性阶”的算法，这正是时间增长趋势所表达的含义。
**时间复杂度的推算方法更简便**。显然，运行平台和计算操作类型都与算法运行时间的增长趋势无关。因此在时间复杂度分析中，我们可以简单地将所有计算操作的执行时间视为相同的“单位时间”，从而将“计算操作的运行时间的统计”简化为“计算操作的数量的统计”，这样的简化方法大大降低了估算难度。
**时间复杂度的推算方法更简便**。显然，运行平台和计算操作类型都与算法运行时间的增长趋势无关。因此在时间复杂度分析中，我们可以简单地将所有计算操作的执行时间视为相同的“单位时间”，从而将“计算操作的运行时间的统计”简化为“计算操作的数量的统计”，这样以来估算难度就大大降低了。
**时间复杂度也存在一定的局限性**。例如，尽管算法 `A` 和 `C` 的时间复杂度相同，但实际运行时间差别很大。同样，尽管算法 `B` 的时间复杂度比 `C` 高，但在输入数据大小 $n$ 较小时，算法 `B` 明显优于算法 `C` 。在这些情况下，我们很难仅凭时间复杂度判断算法效率高低。当然，尽管存在上述问题，复杂度分析仍然是评判算法效率最有效且常用的方法。
## 2.2.3. &nbsp; 函数渐近上界
## 2.2.2. &nbsp; 函数渐近上界
设算法的计算操作数量是一个关于输入数据大小 $n$ 的函数，记为 $T(n)$ ，则以下算法的操作数量为
$$
T(n) = 3 + 2n
$$
给定一个函数 `algorithm()` ：
=== "Java"
@@ -577,14 +597,29 @@ $$
=== "Rust"
```rust title=""
fn algorithm(n: i32) {
let mut a = 1; // +1
a = a + 1; // +1
a = a * 2; // +1
// 循环 n 次
for _ in 0..n { // +1（每轮都执行 i ++）
println!("{}", 0); // +1
}
}
```
$T(n)$ 是一次函数，说明时间增长趋势是线性的，因此可以得出时间复杂度是线性阶。
设算法的计算操作数量是一个关于输入数据大小 $n$ 的函数，记为 $T(n)$ ，则以上函数的的操作数量为：
$$
T(n) = 3 + 2n
$$
$T(n)$ 是一次函数，说明时间的增长趋势是线性的，因此其时间复杂度是线性阶。
我们将线性阶的时间复杂度记为 $O(n)$ ，这个数学符号称为「大 $O$ 记号 Big-$O$ Notation」，表示函数 $T(n)$ 的「渐近上界 Asymptotic Upper Bound」。
推算时间复杂度本质上是计算“操作数量函数 $T(n)$”的渐近上界。接下来，我们来看函数渐近上界的数学定义。
时间复杂度分析本质上是计算“操作数量函数 $T(n)$”的渐近上界。接下来，我们来看函数渐近上界的数学定义。
!!! abstract "函数渐近上界"
@@ -601,9 +636,9 @@ $T(n)$ 是一次函数，说明时间增长趋势是线性的，因此可以得
<p align="center"> Fig. 函数的渐近上界 </p>
从本质上讲，计算渐近上界就是寻找一个函数 $f(n)$ ，使得当 $n$ 趋向于无穷大时，$T(n)$ 和 $f(n)$ 处于相同的增长级别，仅相差一个常数项 $c$ 的倍数。
也就是说，计算渐近上界就是寻找一个函数 $f(n)$ ，使得当 $n$ 趋向于无穷大时，$T(n)$ 和 $f(n)$ 处于相同的增长级别，仅相差一个常数项 $c$ 的倍数。
## 2.2.4. &nbsp; 推算方法
## 2.2.3. &nbsp; 推算方法
渐近上界的数学味儿有点重，如果你感觉没有完全理解，也无需担心。因为在实际使用中，我们只需要掌握推算方法，数学意义可以逐渐领悟。
@@ -613,11 +648,11 @@ $T(n)$ 是一次函数，说明时间增长趋势是线性的，因此可以得
针对代码，逐行从上到下计算即可。然而，由于上述 $c \cdot f(n)$ 中的常数项 $c$ 可以取任意大小，**因此操作数量 $T(n)$ 中的各种系数、常数项都可以被忽略**。根据此原则，可以总结出以下计数简化技巧：
1. **忽略与 $n$ 无关的操作**。因为它们都是 $T(n)$ 中的常数项，对时间复杂度不产生影响。
1. **忽略 $T(n)$ 中的常数项**。因为它们都与 $n$ 无关，所以对时间复杂度不产生影响。
2. **省略所有系数**。例如，循环 $2n$ 次、$5n + 1$ 次等，都可以简化记为 $n$ 次，因为 $n$ 前面的系数对时间复杂度没有影响。
3. **循环嵌套时使用乘法**。总操作数量等于外层循环和内层循环操作数量之积，每一层循环依然可以分别套用上述 `1.` 和 `2.` 技巧。
以下示例展示了使用上述技巧前、后的统计结果。
以下示例展示了使用上述技巧前、后的统计结果。两者推出的时间复杂度相同，即为 $O(n^2)$ 。
$$
\begin{aligned}
@@ -627,8 +662,6 @@ T(n) & = n^2 + n & \text{偷懒统计 (o.O)}
\end{aligned}
$$
最终，两者都能推出相同的时间复杂度结果，即 $O(n^2)$ 。
=== "Java"
```java title=""
@@ -824,7 +857,22 @@ $$
=== "Rust"
```rust title=""
fn algorithm(n: i32) {
let mut a = 1; // +0（技巧 1）
a = a + n; // +0（技巧 1）
// +n（技巧 2）
for i in 0..(5 * n + 1) {
println!("{}", 0);
}
// +n*n（技巧 3）
for i in 0..(2 * n) {
for j in 0..(n + 1) {
println!("{}", 0);
}
}
}
```
### 第二步：判断渐近上界
@@ -835,7 +883,7 @@ $$
<div class="center-table" markdown>
| 操作数量 $T(n)$ | 时间复杂度 $O(f(n))$ |
| 操作数量 $T(n)$ | 时间复杂度 $O(f(n))$ |
| ---------------------- | -------------------- |
| $100000$ | $O(1)$ |
| $3n + 2$ | $O(n)$ |
@@ -845,7 +893,7 @@ $$
</div>
## 2.2.5. &nbsp; 常见类型
## 2.2.4. &nbsp; 常见类型
设输入数据大小为 $n$ ，常见的时间复杂度类型包括（按照从低到高的顺序排列）：
@@ -862,7 +910,7 @@ $$
!!! tip
部分示例代码需要一些预备知识，包括数组、递归算法等。如果遇到不理解的部分，请不要担心，可以在学习完后面章节后再回顾。现阶段，请先专注于理解时间复杂度的含义和推算方法。
部分示例代码需要一些预备知识，包括数组、递归等。如果你遇到不理解的部分，可以在学习完后面章节后再回顾。现阶段，请先专注于理解时间复杂度的含义和推算方法。
### 常数阶 $O(1)$
@@ -1187,10 +1235,6 @@ $$
遍历数组和遍历链表等操作的时间复杂度均为 $O(n)$ ，其中 $n$ 为数组或链表的长度。
!!! question "如何确定输入数据大小 $n$ ？"
**数据大小 $n$ 需根据输入数据的类型来具体确定**。例如，在上述示例中，我们直接将 $n$ 视为输入数据大小；在下面遍历数组的示例中，数据大小 $n$ 为数组的长度。
=== "Java"
```java title="time_complexity.java"
@@ -1357,6 +1401,8 @@ $$
}
```
值得注意的是，**数据大小 $n$ 需根据输入数据的类型来具体确定**。比如在第一个示例中，变量 $n$ 为输入数据大小；在第二个示例中，数组长度 $n$ 为数据大小。
### 平方阶 $O(n^2)$
平方阶的操作数量相对于输入数据大小以平方级别增长。平方阶通常出现在嵌套循环中，外层循环和内层循环都为 $O(n)$ ，因此总体为 $O(n^2)$ 。
@@ -1836,11 +1882,9 @@ $$
### 指数阶 $O(2^n)$
!!! note
生物学的“细胞分裂”是指数阶增长的典型例子：初始状态为 $1$ 个细胞，分裂一轮后变为 $2$ 个，分裂两轮后变为 $4$ 个，以此类推，分裂 $n$ 轮后有 $2^n$ 个细胞。
生物学的“细胞分裂”是指数阶增长的典型例子：初始状态为 $1$ 个细胞，分裂一轮后变为 $2$ 个，分裂两轮后变为 $4$ 个，以此类推，分裂 $n$ 轮后有 $2^n$ 个细胞。
指数阶增长非常迅速，在实际应用中通常是不可接受的。若一个问题使用「暴力枚举」求解的时间复杂度为 $O(2^n)$ ，那么通常需要使用「动态规划」或「贪心算法」等方法来解决。
以下代码模拟了细胞分裂的过程。
=== "Java"
@@ -1848,7 +1892,7 @@ $$
/* 指数阶（循环实现） */
int exponential(int n) {
int count = 0, base = 1;
// cell 每轮一分为二，形成数列 1, 2, 4, 8, ..., 2^(n-1)
// 细胞每轮一分为二，形成数列 1, 2, 4, 8, ..., 2^(n-1)
for (int i = 0; i < n; i++) {
for (int j = 0; j < base; j++) {
count++;
@@ -1866,7 +1910,7 @@ $$
/* 指数阶（循环实现） */
int exponential(int n) {
int count = 0, base = 1;
// cell 每轮一分为二，形成数列 1, 2, 4, 8, ..., 2^(n-1)
// 细胞每轮一分为二，形成数列 1, 2, 4, 8, ..., 2^(n-1)
for (int i = 0; i < n; i++) {
for (int j = 0; j < base; j++) {
count++;
@@ -1885,7 +1929,7 @@ $$
"""指数阶（循环实现）"""
count = 0
base = 1
# cell 每轮一分为二，形成数列 1, 2, 4, 8, ..., 2^(n-1)
# 细胞每轮一分为二，形成数列 1, 2, 4, 8, ..., 2^(n-1)
for _ in range(n):
for _ in range(base):
count += 1
@@ -1900,7 +1944,7 @@ $$
/* 指数阶（循环实现）*/
func exponential(n int) int {
count, base := 0, 1
// cell 每轮一分为二，形成数列 1, 2, 4, 8, ..., 2^(n-1)
// 细胞每轮一分为二，形成数列 1, 2, 4, 8, ..., 2^(n-1)
for i := 0; i < n; i++ {
for j := 0; j < base; j++ {
count++
@@ -1919,7 +1963,7 @@ $$
function exponential(n) {
let count = 0,
base = 1;
// cell 每轮一分为二，形成数列 1, 2, 4, 8, ..., 2^(n-1)
// 细胞每轮一分为二，形成数列 1, 2, 4, 8, ..., 2^(n-1)
for (let i = 0; i < n; i++) {
for (let j = 0; j < base; j++) {
count++;
@@ -1938,7 +1982,7 @@ $$
function exponential(n: number): number {
let count = 0,
base = 1;
// cell 每轮一分为二，形成数列 1, 2, 4, 8, ..., 2^(n-1)
// 细胞每轮一分为二，形成数列 1, 2, 4, 8, ..., 2^(n-1)
for (let i = 0; i < n; i++) {
for (let j = 0; j < base; j++) {
count++;
@@ -1957,7 +2001,7 @@ $$
int exponential(int n) {
int count = 0;
int bas = 1;
// cell 每轮一分为二，形成数列 1, 2, 4, 8, ..., 2^(n-1)
// 细胞每轮一分为二，形成数列 1, 2, 4, 8, ..., 2^(n-1)
for (int i = 0; i < n; i++) {
for (int j = 0; j < bas; j++) {
count++;
@@ -1975,7 +2019,7 @@ $$
/* 指数阶（循环实现） */
int exponential(int n) {
int count = 0, bas = 1;
// cell 每轮一分为二，形成数列 1, 2, 4, 8, ..., 2^(n-1)
// 细胞每轮一分为二，形成数列 1, 2, 4, 8, ..., 2^(n-1)
for (int i = 0; i < n; i++) {
for (int j = 0; j < bas; j++) {
count++;
@@ -1994,7 +2038,7 @@ $$
func exponential(n: Int) -> Int {
var count = 0
var base = 1
// cell 每轮一分为二，形成数列 1, 2, 4, 8, ..., 2^(n-1)
// 细胞每轮一分为二，形成数列 1, 2, 4, 8, ..., 2^(n-1)
for _ in 0 ..< n {
for _ in 0 ..< base {
count += 1
@@ -2014,7 +2058,7 @@ $$
var count: i32 = 0;
var bas: i32 = 1;
var i: i32 = 0;
// cell 每轮一分为二，形成数列 1, 2, 4, 8, ..., 2^(n-1)
// 细胞每轮一分为二，形成数列 1, 2, 4, 8, ..., 2^(n-1)
while (i < n) : (i += 1) {
var j: i32 = 0;
while (j < bas) : (j += 1) {
@@ -2033,7 +2077,7 @@ $$
/* 指数阶（循环实现） */
int exponential(int n) {
int count = 0, base = 1;
// cell 每轮一分为二，形成数列 1, 2, 4, 8, ..., 2^(n-1)
// 细胞每轮一分为二，形成数列 1, 2, 4, 8, ..., 2^(n-1)
for (var i = 0; i < n; i++) {
for (var j = 0; j < base; j++) {
count++;
@@ -2052,7 +2096,7 @@ $$
fn exponential(n: i32) -> i32 {
let mut count = 0;
let mut base = 1;
// cell 每轮一分为二，形成数列 1, 2, 4, 8, ..., 2^(n-1)
// 细胞每轮一分为二，形成数列 1, 2, 4, 8, ..., 2^(n-1)
for _ in 0..n {
for _ in 0..base {
count += 1
@@ -2068,7 +2112,7 @@ $$
<p align="center"> Fig. 指数阶的时间复杂度 </p>
在实际算法中，指数阶常出现于递归函数。例如以下代码，不断地一分为二，经过 $n$ 次分裂后停止。
在实际算法中，指数阶常出现于递归函数。例如以下代码，其递归地一分为二，经过 $n$ 次分裂后停止。
=== "Java"
@@ -2199,13 +2243,11 @@ $$
}
```
指数阶增长非常迅速，在穷举法（暴力搜索、回溯等）中比较常见。对于数据规模较大的问题，指数阶是不可接受的，通常需要使用「动态规划」或「贪心」等算法来解决。
### 对数阶 $O(\log n)$
与指数阶相反，对数阶反映了“每轮缩减到一半的情况”。对数阶仅次于常数阶，时间增长缓慢，是理想的时间复杂度。
对数阶常出现于「二分查找」和「分治算法」中，体现了“一分为多”和“化繁为简”的算法思想。
设输入数据大小为 $n$ ，由于每轮缩减到一半，因此循环次数是 $\log_2 n$ ，即 $2^n$ 的反函数。
与指数阶相反，对数阶反映了“每轮缩减到一半”的情况。设输入数据大小为 $n$ ，由于每轮缩减到一半，因此循环次数是 $\log_2 n$ ，即 $2^n$ 的反函数。
=== "Java"
@@ -2511,6 +2553,8 @@ $$
}
```
对数阶常出现于基于「分治」的算法中，体现了“一分为多”和“化繁为简”的算法思想。它增长缓慢，是理想的时间复杂度，仅次于常数阶。
### 线性对数阶 $O(n \log n)$
线性对数阶常出现于嵌套循环中，两层循环的时间复杂度分别为 $O(\log n)$ 和 $O(n)$ 。
@@ -2705,7 +2749,7 @@ $$
### 阶乘阶 $O(n!)$
阶乘阶对应数学上的「全排列」问题。给定 $n$ 个互不重复的元素，求其所有可能的排列方案，方案数量为：
阶乘阶对应数学上的“全排列”问题。给定 $n$ 个互不重复的元素，求其所有可能的排列方案，方案数量为：
$$
n! = n \times (n - 1) \times (n - 2) \times \cdots \times 2 \times 1
@@ -2905,14 +2949,16 @@ $$
<p align="center"> Fig. 阶乘阶的时间复杂度 </p>
## 2.2.6. &nbsp; 最差、最佳、平均时间复杂度
请注意，因为 $n! > 2^n$ ，所以阶乘阶比指数阶增长地更快，在 $n$ 较大时也是不可接受的。
**某些算法的时间复杂度不是固定的，而是与输入数据的分布有关**。例如，假设输入一个长度为 $n$ 的数组 `nums` ，其中 `nums` 由从 $1$ 至 $n$ 的数字组成，但元素顺序是随机打乱的；算法的任务是返回元素 $1$ 的索引。我们可以得出以下结论：
## 2.2.5. &nbsp; 最差、最佳、平均时间复杂度
- 当 `nums = [?, ?, ..., 1]` ，即当末尾元素是 $1$ 时，需要完整遍历数组，此时达到 **最差时间复杂度 $O(n)$** 。
- 当 `nums = [1, ?, ?, ...]` ，即当首个数字为 $1$ 时，无论数组多长都不需要继续遍历，此时达到 **最佳时间复杂度 $\Omega(1)$** 。
**算法的时间效率往往不是固定的，而是与输入数据的分布有关**。假设输入一个长度为 $n$ 的数组 `nums` ，其中 `nums` 由从 $1$ 至 $n$ 的数字组成，但元素顺序是随机打乱的，任务目标是返回元素 $1$ 的索引。我们可以得出以下结论：
“函数渐近上界”使用大 $O$ 记号表示，代表「最差时间复杂度」。相应地，“函数渐近下界”用 $\Omega$ 记号来表示，代表「最佳时间复杂度」。
- 当 `nums = [?, ?, ..., 1]` ，即当末尾元素是 $1$ 时，需要完整遍历数组，**达到最差时间复杂度 $O(n)$** 。
- 当 `nums = [1, ?, ?, ...]` ，即当首个数字为 $1$ 时，无论数组多长都不需要继续遍历，**达到最佳时间复杂度 $\Omega(1)$** 。
「最差时间复杂度」对应函数渐近上界，使用大 $O$ 记号表示。相应地，「最佳时间复杂度」对应函数渐近下界，用 $\Omega$ 记号表示。
=== "Java"
@@ -3264,15 +3310,13 @@ $$
}
```
!!! tip
值得说明的是，我们在实际中很少使用「最佳时间复杂度」，因为通常只有在很小概率下才能达到，可能会带来一定的误导性。**而「最差时间复杂度」更为实用，因为它给出了一个效率安全值**，让我们可以放心地使用算法。
实际应用中我们很少使用「最佳时间复杂度」，因为通常只有在很小概率下才能达到，可能会带来一定的误导性。相反，「最差时间复杂度」更为实用，因为它给出了一个“效率安全值”，让我们可以放心地使用算法。
从上述示例可以看出，最差或最佳时间复杂度只出现在“特殊分布的数据”中，这些情况的出现概率可能很小，因此并不能最真实地反映算法运行效率。相较之下，**「平均时间复杂度」可以体现算法在随机输入数据下的运行效率**，用 $\Theta$ 记号来表示。
从上述示例可以看出，最差或最佳时间复杂度只出现于“特殊的数据分布”，这些情况的出现概率可能很小，并不能真实地反映算法运行效率。相比之下，**「平均时间复杂度」可以体现算法在随机输入数据下的运行效率**，用 $\Theta$ 记号来表示。
对于部分算法，我们可以简单地推算出随机数据分布下的平均情况。比如上述示例，由于输入数组是被打乱的，因此元素 $1$ 出现在任意索引的概率都是相等的，那么算法的平均循环次数则是数组长度的一半 $\frac{n}{2}$ ，平均时间复杂度为 $\Theta(\frac{n}{2}) = \Theta(n)$ 。
但在实际应用中，尤其是较为复杂的算法，计算平均时间复杂度比较困难，因为很难简便地分析出在数据分布下的整体数学期望。在这种情况下，我们通常使用最差时间复杂度作为算法效率的评判标准。
但对于较为复杂的算法，计算平均时间复杂度往往是比较困难的，因为很难分析出在数据分布下的整体数学期望。在这种情况下，我们通常使用最差时间复杂度作为算法效率的评判标准。
!!! question "为什么很少看到 $\Theta$ 符号？"