Python 学线性代数与微积分：避开“程序没报错结果却错”的三大坑

简介：《程序员数学》是一本面向 IT 从业者、用 Python 讲解线性代数与微积分的专著。这份配套源码与书中章节一一对应，涵盖向量运算、矩阵乘法、行列式、特征值与特征向量、线性空间与线性变换，以及极限、导数、积分等核心模块，适合通过编码实践理解抽象概念的开发者。资源共 104 个文件：74 个 Python 脚本为主体，17 个 Jupyter Notebook 用于交互式可视化演示，另有示意图、三维模型文件与说明文档等附件；整包仅 13.55MB，目录按章节组织，便于检索。作者已对书内原有代码错误做了修正与封包处理，避免读者在复现中踩坑。Notebook 可动态展示函数图形与导数、多角度观察矩阵变换的几何意义，帮助直观掌握线性代数与微积分核心思想。该资源已有 1652 人学习下载，适合想用 Python 学透数学、提升数学素养和编程能力的初学者及进阶开发者。

1. 程序没报错结果却全错：用 Python 学透线性代数和微积分的第一道坎

某个夜里，一位同学把教材配套源码里的一段代码发给我，说运算结果跟书里答案差太多。我跑了一遍，没有异常、没有警告、进程正常退出，算出来的数字却差得离谱。这种故障最磨人：程序在告诉你它跑通了，但每一行输出都在明摆着说“结果不可信”。检查括号、检查大小写、检查依赖版本，逐行看到眼酸也找不出问题，最后才意识到错根本不在代码本身，而在代码所依据的数学约定。

这正是用 Python 学线性代数和微积分时最常见的坎：书里写的是数学记号，屏幕上是编程语言，两套习惯在索引、浮点精度、符号方向这三个层面各有偏差，现象整齐划一——“程序没报错，结果一直不对”。这篇文章是一份排错记录，把这份《程序员数学》配套源码里修过的问题按索引、浮点、公式三类拆开，每类都给出复现命令和修复代码。卡在结果对不上的读者可以照着操作，想弄懂根因的读者也能看到完整定位思路。

2. 线性代数计算结果和教材对不上：三个隐形故障与修复记录

读完教材，最自然的验证方式就是把书里的矩阵原样敲进 Python，再用 NumPy 算出结果去比对。这个过程中，显式报错反而好收拾，难缠的是三类静默错误：下标偏移、浮点噪声、符号方向。它们不会触发任何异常，只会让结果偏离参考答案一点点，而这一点点足以毁掉你后面所有的判断。

2.1 书里“第1行”其实是 Python 的“第0行”：索引偏移引发的整体错位

现象复现

教材里的矩阵计数通常从 1 开始，比如这样一个 3×3 矩阵：

import numpy as np A = np.array([[1, 2, 3], [4, 5, 6], [7, 8, 9]])

教材说“取第 1 行第 2 列元素”，你想当然写成A[1][2]，运行结果却不是书上的 2，而是 6。再试A[0][1]，才得到 2。单独看一段代码你可能觉得只是手误；但当这个差错进入矩阵乘法、转置、内积的链条后，每次输出都带偏一点，最终结论必然对不上。

根因

数学和编程各有一套互不相让的约定：教材的下标从 1 开始，NumPy 的下标从 0 开始。差 1 的错位在矩阵类运算里会被一层层放大，且不报任何异常，属于最不容易察觉的 bug。更麻烦的是，这种错误往往到验证答案阶段才暴露，那时你已经写了大量代码，回头定位成本很高。

解决

def get_entry(M, row, col): """row, col 按教材习惯从 1 开始计数，函数内统一换算成 0 基下标""" return M[row - 1, col - 1] print(get_entry(A, 1, 2)) # 2，符合教材

逻辑说明：row - 1、col - 1完成从教材坐标到数组下标的换算。关键不在于减不减 1，而在于把换算收口到一个函数里，而不是在每处切片处手写偏移——手写偏移是索引类 bug 的源头。

参数说明：如果矩阵超过二维，同样的减一映射要复用到第三维，比如M[row - 1, col - 1, page - 1]。另外，拿到矩阵后先做一次形状断言：

assert A.shape == (3, 3), "数组维度与教材不一致"

这句断言的作用，是把“算出来的答案不对”提前变成“读取阶段就报错”，让问题在早期暴露。我习惯在每个矩阵运算入口前加一个 shape 断言，成本几乎为零，收益非常大。

2.2 行列式算出 1e-16 而不是 0：浮点精度污染数学判定

现象复现

某个矩阵理论上的行列式是 0，教材说它是奇异矩阵、求逆会失败。于是你写：

if np.linalg.det(A) == 0: print("矩阵不可逆")

可代码运行到np.linalg.inv(A)时抛了LinAlgError: Singular matrix。为什么明明判定了，却没走进“不可逆”分支？因为np.linalg.det(A)返回的并不是 0，而是一个离 0 很近、但严格不等于 0 的数，比如-1.1102230246251565e-16。

根因

双精度浮点数并不能精确表示所有实数，矩阵求逆和行列式计算的时间代价会把误差一步步放大。对奇异矩阵，理论上的 0 在浮点世界里会被代换成 1e-16 量级的残余噪声。== 0是绝对判断，浮点结果恰好为 0 的概率极低——这就是程序明明按“数学逻辑”写、却得不到数学结论的原因。

解决

det = np.linalg.det(A) if np.isclose(det, 0.0, atol=1e-8): print("det 接近 0，矩阵视为奇异") else: print("det =", det)

逻辑说明：np.isclose(det, 0.0, atol=1e-8)的意思是“若 det 与 0 的绝对差小于 1e-8，就认为两者相等”。1e-8 比 1e-16 大 8 个数量级，足以覆盖浮点舍入；但若矩阵元素本身数值极大，det 的正常值也可能在 1e6 量级，这时 atol 要相应调大，或者改用相对容忍度rtol=1e-9。

失败时进一步看什么

行列式不是判断可逆性的唯一标准。矩阵接近奇异但不完全奇异时，det 无法稳定区分“可逆”与“病态”。更可靠的指标是条件数：

cond = np.linalg.cond(A) print(cond) if cond > 1e12: print("矩阵病态，请谨慎求逆或求解")

条件数大于 1e12 时，即使逆矩阵能求出来，数值结果也极可能不可信。做线性方程求解类实验时，教材通常只教 det != 0 的判断，实际排错要把这个判断升级为条件数判定——这也是我在这份源码里做的一类典型修正。别再拿 det == 0 判断可逆性，这是我早年交过的一笔血泪学费。

2.3 特征向量方向反了：不是 bug，但会误导你的验证

现象复现

用np.linalg.eig(A)求特征值和特征向量，结果和教材答案对不上：教材写着特征向量是[1, 1]，代码给出[-1, -1]。对着屏幕看半天，你会怀疑是自己把特征向量和特征值对应反了，或者矩阵敲错了。

根因

特征向量有个数学性质：任意非零常数倍仍是特征向量。LAPACK 底层的求解算法只保证方向不变，不保证符号为正。同一段代码在不同平台上可能给出正负相反的结果。这不是程序错误，但在拿代码结果与教材比对时，会被误判成“实现有 bug”。

解决

def normalize_vector(v): """把向量方向统一下，方便和教材答案对比""" v = np.asarray(v, dtype=float) idx = np.argmax(np.abs(v)) # 找绝对值最大的分量 if v[idx] < 0: v = -v return v / v[idx] eigenvalues, eigenvectors = np.linalg.eig(A) v0 = normalize_vector(eigenvectors[:, 0]) print(v0)

逻辑说明：np.argmax(np.abs(v))定位绝对值最大的分量位置；若该分量为负，则整体取反，之后用v[idx]归一化，使最大分量变为 1。这样处理后再和书上的特征向量对比，符号方向就不再干扰结论。

注意

当特征值存在重根时，特征向量不唯一，NumPy 返回的一组基向量和教材写的不同并不代表错误。此时不能拿单个向量做比较，而应该比较两组向量张成的子空间。做法是分别做 Gram 矩阵，检查秩是否相等、互相能否线性表出；只看单个向量，是验证这类结论时最容易产生的误会。我在代码里常备一个子空间对比函数，专门处理重根特征向量的检验。

3. 微积分结果跑偏：求导、积分与教材不一致的排查记录

数学类代码里最不好查的，不是语法错误，而是“算出来的数离理论值差一点”。微积分这一章里，数值微分和数值积分的误差来源，往往被新手误当成“抄错了公式”或“环境坏了”。实际排查时，应从算法本身的精度开始逐层排除。

3.1 数值微分精度不够：前向差分换成中心差分

现象复现

教材配套代码里最常见的一版导数实现是前向差分：

def diff_forward(f, x, h=0.01): return (f(x + h) - f(x)) / h

对f(x) = x²在 x=3 处求导，理论值是 6，这段代码返回 6.01 左右。你以为自己取错了 h，把 h 改得越来越小，结果到了1e-12时，结果不是更接近 6，而是变成 0 或乱跳。明明改进了步长，结果反而更糟。

根因

前向差分的截断误差是 O(h)，h=0.01 时理论误差在百分位，看起来当然对不上。h 太小则落入另一层问题：两个足够接近的浮点数相减时，有效位数被大幅削减，产生“灾难性抵消”。数学上 h 越小越精准，浮点世界里 h 太小结果反而报废。

解决

def diff_central(f, x, h=1e-6): """中心差分公式，截断误差 O(h²)""" return (f(x + h) - f(x - h)) / (2 * h) print(diff_central(lambda t: t**2, 3.0)) # 输出为 6.000000000039306，误差在 1e-11 量级

逻辑说明：中心差分的对称形式使其一阶误差项被抵消，精度从 O(h) 提升到 O(h²)；分母 2h 对应区间跨度。h=1e-6 是实际工程中的常用折中：在 64 位浮点机器精度约 2.2e-16 的条件下，它既不太大，避免截断误差占主导，又不太小，避免抵消误差占主导。

失败时看什么

写一个循环，分别取 h 为 1e-2、1e-4、1e-6、1e-8，打印每次的导数值：

for h in [1e-2, 1e-4, 1e-6, 1e-8, 1e-10]: print(h, diff_central(lambda t: t**2, 3.0, h))

结果通常先随 h 减小而趋近理论值，到某个临界点后开始抖动；取临界点之前那个 h 即可。这其实就是网上常说的“步长玄学”，背后的定量规律就是截断误差与舍入误差的平衡。更高阶导数的验证，我一般直接用 SymPy 做符号求导当基准：

import sympy as sp x = sp.Symbol('x') print(sp.diff(x**2, x)) # 输出 2*x

这样就把“跟教材对答案”变成“跟符号引擎对答案”，后者几乎不会算错。

3.2 定积分结果离谱：先查步长和端点，再查公式本身

现象复现

教材给出一个用梯形法则算定积分的例子，你照着实现，结果比参考答案大了好几个量级，甚至出现inf或nan。改步长效果也不明显——n 从 1000 加到 100000，结果纹丝不动或慢吞吞地变。多数人这时会去换积分方法，从梯形换辛普森，或者引入 scipy.integrate，但问题可能根本不在算法。

根因

最常见原因是被积函数在积分区间内部或端点存在奇异点。例如f(x) = 1/x，区间左端从 0 开始，梯形法则在每个小区间上都用直线近似，但奇异点处的函数值直接是无穷或未定义，之前的采样全部失去意义。另一种情况是函数振荡剧烈，比如含有sin(100x)的项，均匀网格的梯形法则会漏掉波峰波谷，误差不会随 n 增大而有效下降。

解决

调试第一步不是换积分方法，而是把采样点打印出来检查。写一个带保护的梯形积分：

import numpy as np def trapz_safe(f, a, b, n): """梯形法则，先检测被积函数的奇异点，再积分""" xs = np.linspace(a, b, n + 1) ys = np.array([f(x) for x in xs], dtype=float) if not np.all(np.isfinite(ys)): bad = np.where(~np.isfinite(ys))[0] for i in bad: print(f"非有限值出现在 x = {xs[i]}") return None return np.trapezoid(ys, xs)

逻辑说明：np.linspace(a, b, n + 1)生成均匀分点；np.isfinite(ys)逐个检查是否出现 inf、-inf、nan，一旦发现就打印具体坐标，排错直接定位到奇异点。np.trapezoid是 NumPy 2.0 起推荐的写法，旧版本用np.trapz，两者作用相同。

参数说明：n是区间分段数，步长h = (b - a) / n。光滑函数时梯形法则误差约 O(h²)，n 从 100 提到 10000，误差大约从 1e-4 降到 1e-8；遇到不连续或振荡函数，加 n 往往无效，二次排查时可以画出采样点图，看是不是漏掉了函数本身的波动。

如果确认函数在区间内部确实存在奇点，正确做法是把区间拆成两个子区间分别积分，再相加。教材为了简化例题经常回避这类边界情况，这也是配套源码会把“闭区间直接积分”修正成“先检测奇异点再分段积分”的原因之一。

3.3 教材公式本身勘误：怎样用符号计算做权威对照

现象复现

某次推导，教材里求f(x) = x³ + 2x的导数，步骤写出的结果是3x + 2，而你记忆里的答案是3x² + 2。两头一对比，源码实现、运行环境、依赖版本全都没问题，问题出在教材本身的抄录或印刷错误上。这种情况在数学类书籍里不罕见：批量排版的公式多，笔误常出现在幂指数、符号正负和常数系数上。

解决

把教材的公式当成“待验证的输入”，而不是权威基线。用符号计算引擎先跑一遍：

import sympy as sp x = sp.Symbol('x') f = x**3 + 2*x print(sp.diff(f, x)) # 3*x**2 + 2

逻辑说明：SymPy 的sp.diff是符号求导，不涉及数值逼近，结果在数学定义下是精确的。拿它和教材结果对比，能迅速判断“公式错”还是“代码错”。微积分类习题里一切“跟标准答案对不上”的争执，我最终的仲裁依据都是符号计算的输出。

这也是这份教材源码存在的意义之一：它把随书代码里的公式错误逐行修正过，并在注释里保留了原始错误与修正后的对照。标准工作流是：先跑一遍修正版作为黄金参考，再去看自己的代码和修正版到底在哪一行分叉。如果只有二分叉、没有语法报错，用文件对比工具把两份代码 diff 一下，一眼就能看到被改掉的是哪个系数、哪个指数。

4. 避坑清单：跟着教材抄 Python 代码最容易翻车的五个现场

以下五个坑是按照实际踩坑频率排的。每一条都按“现象 → 原因 → 解决”来写，直接翻到自己遇到的那条照做即可。

4.1 现象：import sympy 报 ModuleNotFoundError，代码卡在第一行

现象：拿到源码目录直接跑，第 1 行import numpy或import sympy就报错，后面代码一句没执行。

原因：教材给的是代码片段，没有把第三方库的安装步骤写进去。常见的是缺 sympy，或者在新版 Python 上装了过旧的 numpy 导致依赖冲突。软件环境本身不完备，跟代码逻辑无关，但卡住的时间一样久。

解决：

python -m pip install "numpy>=1.20" "scipy>=1.8" "sympy>=1.10" "matplotlib>=3.5"

逻辑说明：这里显式指定了最低版本，避免“装上但版本太旧”的隐性坑。安装后立刻跑一条验证命令，确认环境就绪再继续：

python -c "import numpy, sympy, scipy, matplotlib; print('env ok')"

参数说明：>=表示最低版本约束。如果原环境已经有别的项目在使用，不要直接装到全局环境，先建虚拟环境再装，这是环境类报错的标准处理方式。

4.2 现象：矩阵乘法报 ValueError: shapes not aligned

现象：教材说 A 是 m×n、B 是 n×p，但代码一执行就报ValueError: shapes (m,n) and (m,p) not aligned；不报错的版本给出的结果又和参考答案完全不同。

原因：把教材中的矩阵转置关系抄错了。常见的是表达式里出现A^T或B^T，代码里却直接用了原始变量；也可能是形状恰好能乘，但数学意义不对，输出自然失真。

解决：

print("A.shape =", A.shape, "B.shape =", B.shape) # 先打印形状确认，再执行乘法 C = A @ B.T if use_transpose else A @ B

逻辑说明：打印 shape 是这类问题的第一道防线。矩阵乘法@和逐元素乘法*完全不同：*做的是对应位置相乘，形状不合适时会触发广播，让你看到的结果看起来合理、实际却没做矩阵乘法。看到 shapes not aligned 先别查矩阵内容，先查 shape。

4.3 现象：同一套代码，换台机器结果就不同

现象：在公司电脑上跑教材代码结果正确，回到自己的电脑，同一份代码输出在十位小数处发生变化，个别矩阵运算结果的差距甚至放大到百位。

原因：不同机器底层用的 BLAS/LAPACK 实现不同，多线程行为也不同；浮点相对位置相同的两个数，在不同并行求和顺序下尾数会不同。这不是代码 bug，而是浮点计算的内在不确定性，也是线性代数这类数值算法跨平台复现时最常见的现象。

解决：

import numpy as np print(np.allclose(result, expected, rtol=1e-5, atol=1e-8))

逻辑说明：rtol=1e-5是相对容差，矩阵元素在 1e3 量级时允许 0.01 的误差；atol=1e-8防止绝对值为 0 的元素被误判。所有“跨平台结果验证”都统一走这个方式，代替肉眼比对打印结果。

4.4 现象：用 round() 修浮点数，越修越不对

现象：教材打印结果保留四位小数，你用round(x, 4)处理每一个中间量，最后结果和参考答案差 0.01。

原因：Python 的round()实现的是银行家舍入（round half to even）：round(0.5)为 0，round(2.5)为 2。循环中多次舍入时，误差会系统性累积而不是随机抵消，这是“四舍五入越用越错”的经典翻车现场。

解决：

print(f"{result:.4f}") # 格式化，只在输出时生效

逻辑说明：格式化字符串不改变底层数值，只在打印的瞬间生成四舍五入后的文本。要保留四位小数的数组数据则用np.round(arr, 4)，且放在计算链的最末端，不要在中间步骤反复舍入。

4.5 现象：判断输出和教材答案是否一致，用 == 全为 False

现象：你写if matrix_result == book_answer:，返回一个全是 False 的布尔矩阵，但用肉眼对照每一步小数，发现它们明明“差不多”。

原因：==对浮点数做逐元素严格比较，运算过程中极小误差（如 1e-15）就会导致不等。这是 2.2 小节的同款问题，在微积分习题验证里同样天天出现。

解决：

if np.allclose(matrix_result, book_answer, atol=1e-6): print("结果在容差范围内一致") else: print("结果不一致，定位中间层")

逻辑说明：np.allclose先做形状匹配，再逐元素比较，把确定性相等退化为容差判断。这是验证脚本的核心断言，排错时遇到“程序没报错但结果不像”的情况，都先用它做快速初筛，再决定要不要打印中间值。

5. 快速定位这类问题：四步排查法和一个验证脚本

用代码学数学，真正的耗时不在写，而在对答案时找“不对在哪”。基于处置教材源码的经验，我把定位过程压缩成四步。步骤不能跳：一旦先改代码再找根因，很容易去掉一个真错误，又引入一个新的。

第一步，打印中间量。把矩阵乘法前后的形状、特征分解后的特征值顺序、数值微分的每个分步结果全部打印。多数情况下错误一眼可辨，比如转置导致 shape 错位、特征值的顺序和教材不同等等。打印比断点好用，因为在数学计算里，数据不正常往往先于控制流不正常。

第二步，构造最小可手算样本。选一个 2×2 矩阵或一个多项式函数，它的解析答案完全可以心算，用待验证代码先把这个样本跑出来，再手算一遍。两者一致说明实现本身可靠，不一致说明代码大概率有 bug。最小样本的目的，是把教科书复杂例题里的干扰因素剥离干净。

第三步，隔离“书”和“代码”。拿教材答案作为一方，拿运行结果作为另一方，两者对不上时用 SymPy 求第三值，错在谁就明确了。如果是公式层面不一致，属教材勘误；如果 SymPy 与运行结果一致但都与教材不同，说明代码忠实实现了教材里的印刷错误。两种处理方向完全不同，不能混为一谈。

第四步，自动断言交给 np.allclose。肉眼比对 10 位小数既不现实也不可靠；肉眼负责定位，自动断言负责验证。把验证固化成一个通用函数，放到每个习题里调用：

import numpy as np def verify(label, actual, expected, atol=1e-6): if np.allclose(actual, expected, atol=atol): print(f"[PASS] {label}") else: print(f"[FAIL] {label}") print(f" actual = {actual}") print(f" expected = {expected}")

这个骨架可以直接套到矩阵、导数、积分的结果验证上，实际值、期望值、允许误差三者一目了然。最后附一张我常用的故障对照表，遇到具体报错直接查：

从那以后，我在每次数学实验里都强制走一遍这四步，做完四步才敢写结论。多数“程序没报错但结果不对”的数学代码问题，都能在 20 分钟内定位完毕，而不是耗掉一个下午。卡在这类问题上的开发者，希望这份排错记录能帮到你。

本文还有配套的精品资源，点击获取