1. 浮点数到底存的是什么——它不是你以为的那个数1.1 先看一个让人怀疑人生的例子如果让你预测下面这行代码的结果你大概率会毫不犹豫地说输出是true#include stdio.h int main(void) { float a 0.1f; float b 0.2f; printf(%d\n, a b 0.3f); return 0; }但真实输出是 0也就是不相等。如果把float换成double再来一句经典对话 0.1 0.2 0.30000000000000004很多人第一次遇到这个结果时都会怀疑编译器坏了。实际上不是编译器的问题而是浮点数的底层表示方式决定了它根本没法精确表示 0.1 这个十进制小数。从今天起你可以把这个例子当成理解浮点数的一把钥匙凡是写着“浮点数运算”四个字的地方本质上都默认了一个前提——你接受“近似”作为计算的常态。浮点数的应用范围广到离谱从单片机里的温度采样到机器人控制系统的坐标插补再到科学计算里的矩阵求逆几乎全是浮点数的天下。网上热搜里的库卡机器人把 32 个输入信号定义为浮点数本质上就是在用浮点数表达连续物理量。所以搞懂浮点数怎么存、怎么算、怎么比较不是考试需求而是工程刚需。1.2 从科学计数法到二进制科学计数法十进制里我们早就习惯了科学计数法12345 可以写成 1.2345 × 10^4也就是把一个数拆成“有效数字 × 基数幂”的结构。这样做的好处很明显同样表达一个数有效数字负责精度指数负责范围两者解耦。浮点数只是把这种思路搬到二进制里。二进制的科学计数法长这样1.0101 × 2^3其中1.0101是尾数有效数字3是指数2是基数。计算机存储浮点数时只需要存三个部分符号位、指数位、尾数位。但麻烦在于十进制里能精确写出来的小数换成二进制不一定能精确写出来。比如十进制 0.1换算成二进制时是这样的无限循环小数0.0001100110011001100110011001100110011...因为计算机的存储位数是有限的所以它只能截断或四舍五入到有限位存下来的 0.1 已经是一个和理论值非常接近、但绝对不等于理论值的近似数。这就是浮点数一切诡异行为的根源。1.3 双精度浮点数的布局和那些“看不见的位”目前全世界的计算机基本都遵守 IEEE 754 标准我对这个标准的评价就一个字绝。它把浮点数的存储安排得非常巧妙。以最常用的双精度浮点数double为例它占 64 位拆成三部分符号位1 位0 表示正1 表示负指数位11 位用来存“偏移后”的指数尾数位52 位用来存有效数字的小数部分。单精度浮点数float同理结构是符号位 1 位、指数位 8 位、尾数位 23 位。C 语言里float是单精度double是双精度这个大家应该很熟悉。一个容易被忽视的设定是IEEE 754 里的规格化浮点数尾数始终写成1.xxxxx的形式也就是说小数点前固定是 1。既然固定是 1那这一位就不需要实际存进去计算机默认它存在这叫“隐含位”或“隐藏位”。这相当于凭空多给了你一位精度设计上非常划算。举个例子双精度 1.5 的尾数部分实际存储在 52 位里的是1000...这种形式最前面的 1 是隐含的不会占用存储空间。理解这个隐含位后面理解规格化数和精度上限就很顺手了。2. 规格化、精度和取值范围别再只会背范围2.1 为什么非要有“规格化”这个概念上网搜“浮点数的规格化”你会发现一堆教材在处理这个问题。规格化到底解决什么核心就一句话让同一个数尽量只有一种表示方式。如果不做规格化二进制科学计数法里 1.5 可以写成 1.1 × 2^0也可以写成 0.11 × 2^1还能写成 11 × 2^(-1)。同一个数有无数种写法计算机存储和比较都会变得极麻烦。规格化强制要求尾数满足1.xxx这种格式指数通过偏移量来适配这样每个数就有了统一的表达。还有一个更深层的收益规格化之后尾数的有效位数被充分利用了。比如双精度的 52 位尾数如果允许前导 0那同一个数值范围里很大一部分存储会被浪费精度就会下降。强制1.xxx后这一位隐含的 1 把有效精度拉满。关于指数位IEEE 754 用了一个叫“偏置值”的技巧。单精度指数范围是 8 位能表示 0 到 255但实际指数允许有正有负。标准规定实际指数 存储值 - 127双精度是 1023。也就是说存储值 127 代表实际指数 0存储值 130 代表实际指数 3。这样设计的好处是比较两个浮点数大小时可以像比较无符号整数一样先去比指数位硬件实现简单速度还快。2.2 特殊值、非规格化数和边界情况IEEE 754 里指数位不是随便用的它留出了两组特殊情况指数位全为 0表示 0 或非规格化数subnormal number。0 的符号位可以是正也可以是负于是有了 0 和 -0。非规格化数用来填补 0 附近的最小间隔让很小的数不至于直接下溢成 0代价是精度下降。指数位全为 1表示无穷大Infinity或 NaNNot a Number。比如 1.0 / 0.0 在 IEEE 754 里得到正无穷0.0 / 0.0 得到 NaN。NaN 还有一个特性它不等于任何数包括它自己。很多人对非规格化数没概念但实际使用中它会造成一个非常隐蔽的性能坑。我在做数值计算时遇到过循环里一旦产生了大量非规格化数同样一次浮点加法可能比正常数慢十几倍甚至几十倍原因是很多 CPU 处理非规格化数要额外走异常流程。后来我查资料才知道这事情在信号处理领域被讨论了无数次解决办法是在编译或运行时开启“将非规格化数刷为 0”flush-to-zero模式。普通工程师可能一辈子遇不到但在嵌入式或高性能计算场景这个坑值得知道。2.3 双精度到底能表示多大的数、多精确的数先背范围再谈感觉。类型位数有效十进制精度最大有限值最小正规格化数float32约 7 位约 3.4 × 10^38约 1.2 × 10^(-38)double64约 15 位约 1.8 × 10^308约 2.2 × 10^(-308)FP1616约 3 位65504约 6.1 × 10^(-5)“有效十进制精度约 15 位”的意思是double 能保证你写出 15 位有效数字时回读和写入基本一致但第 16、17 位就开始不确定了。很多初学者以为 double 能表示的整数是连续到 2^53这个理解也半对。因为双精度尾数是 52 位加上隐含位一共 53 位有效二进制位。所以它能精确表示所有绝对值小于 2^53 的整数但超过 2^53 后相邻整数之间开始出现空隙。也就是9007199254740992这个数之后你加 1 也可能被舍入回原值。我见过有人用 double 存订单号存到后面发现订单号变了就是这个原因。精确的整数别用二进制浮点数这是第一条血泪教训。3. 浮点数运算的真实过程对阶、舍入和误差累积3.1 加减法为什么要“先对阶”浮点数的加减法和手算科学计数法一模一样先把指数对齐到较大的那个然后尾数相加减最后再规格化。关键是“对阶”这一步它对不上号。对阶的本质是把两个数的小数点位置对齐。比如计算 1.25 × 10^2 1.5 × 10^1你得先把 1.5 × 10^1 改成 0.15 × 10^2然后加尾数得到 1.40 × 10^2。二进制浮点数也是这个流程只不过尾数位数有限如果两个数的指数差得太大较小的数的尾数在右移过程中会被直接移出有效位。举例来说double x 1e20; double y x 1.0 - x; printf(%.0f\n, y); // 输出 0这里1e20的指数和1.0差了太多对阶时1.0的全部有效位都掉出了 52 位尾数于是x 1.0得到的还是x减掉 x 后得到 0。你本来想算“1”结果拿到的是 0。这个问题的学名叫“大数吃小数”工程里非常常见。做累加时也一样。如果你把一个较大的数反复加较小的增量增量可能在第一次累加就被吞掉。很多控制程序里的积分项误差最后就演变成系统误差根源往往就在这里。3.2 浮点数乘法指数相加尾数相乘无穷和下溢浮点数乘法比加法直观一些符号位异或指数位相加后再减掉偏置值尾数相乘然后规格化。看起来简单但有两个必须注意的坑。第一个坑是上溢和下溢。两个很大的数相乘指数相加后可能超过指数位的上限结果变成无穷大两个很小的数相乘结果可能下溢到 0。在写矩阵运算时我习惯于先做归一化再计算比如把矩阵每行先除以行最大值再进入乘法流程这样能大幅度减少上下溢风险。第二个坑是尾数相乘的额外精度问题。两个 52 位尾数相乘理想结果最多需要 104 位才能精确表示但硬件寄存器通常只保留扩展精度最终还是要舍入回 52 位。这意味着每次乘法都会引入一次舍入误差。多个乘法误差叠加起来就不是简单“四舍五入”四个字能糊弄过去的了。我还想提一个容易被忽略的点浮点数乘法本身是可交换的a × b 等于 b × a但在计算机里它不一定可结合。也就是说(a × b) × c和a × (b × c)的结果可能有细微差别。这个性质在并行计算和编译器优化里非常折腾人我遇到过团队为了性能开快速数学优化选项结果数值结果和原来对不上最后把优化选项关掉才恢复。3.3 误差累积与算法稳定性误差并不可怕可怕的是误差在计算过程中被放大。这里请记住一个词算法稳定性。举个典型例子数值积分的朴素累加double sum 0.0; for (int i 1; i 1000000; i) { sum 1.0 / i; }这个循环的误差累积会随着项数增多而增加因为每一轮加法都有一次舍入总和越来越大而后续增量相对总和越来越小大数吃小数的效应开始显现。改进方案之一是倒着累加从最小的项加起误差明显更小另一个方案是 Kahan 求和它用一个补偿变量记录每次舍入掉的误差然后在下一次加法时补回去。Kahan 求和的思路我复述一下维护一个c表示上次运算丢掉的部分每算一个新加数y先让y - c再与sum相加最后把这次的误差存回c中。用代码表示就是double kahan_sum(double *a, int n) { double sum 0.0; double c 0.0; for (int i 0; i n; i) { double y a[i] - c; double t sum y; c (t - sum) - y; sum t; } return sum; }这段代码第一眼看去不太直观但实际测试效果很惊人同样是累加 100 万个浮点数普通累加的误差可能在 1e-10 量级Kahan 求和能把误差压到 1e-15 以下。工程上如果对精度有硬指标别嫌麻烦这种补偿算法值得写进去。4. C语言判断浮点数相等一个老生常谈但必须说透的问题4.1 为什么不能直接用 C 语言初学者几乎都被这样教育过浮点数不能直接比较。但很少有人把原理说透。其实前面的内容已经给了答案浮点数存储的是近似值而且同一个十进制数从不同路径计算可能得到不同的近似值。看这段代码double a 0.1; double b 0.1; printf(%d\n, a b); // 可能输出 1没问题看起来直接比较没问题但换一种写法double a 0.1; double b 1.0 / 10.0; printf(%d\n, a b); // 可能输出 1因为编译器通常也把它化成同一个近似值再换double a 0.1; double b 0.2; double c a b; printf(%d\n, c 0.3); // 输出 0问题就出现了。0.1 0.2的实际结果是一个逼近 0.3 但并非 0.3 的二进制数而字面量0.3本身也是另一个逼近 0.3 的二进制数两个近似值不是同一个比较自然不成立。所以“不能用 ”这句话的本质是你在比较两个各自都有误差的数误差方向不同结果自然不稳定。4.2 最简单的绝对误差阈值法最朴素的做法是看两个数的差的绝对值是否小于某个你认为可以接受的误差#include math.h int double_equal(double a, double b, double epsilon) { return fabs(a - b) epsilon; }然后调用的时候传一个自己定义的epsilon比如1e-9。这个方法直观但坑也不少。第一个坑是数量级问题。如果你想比较的两个数本身都在 1e12 量级那么它们之间的合理误差可能也很大用1e-9这种绝对阈值算法会永远认为它们不相等。反过来如果两个数都在 1e-12 附近用1e-9做阈值又会让所有数都被判定为相等。绝对误差只适合在你知道数量级比较接近的场景里用比如传感器同一量程内的读数比较。第二个坑是 epsilon 到底取多少。取小了正常误差也被判为不相等取大了真正的差异又被掩盖。工程上我一般会结合数据的物理单位来确定比如坐标误差允许 1 毫米那就直接传 0.001而不是拍脑袋传一个通用值。4.3 相对误差法适应不同数量级的通用比较法既然绝对误差受数量级影响那就用相对误差。相对误差的思想是允许的误差和数据本身的大小成比例。一个比较通行的 C 语言实现是这样#include math.h int nearly_equal(double a, double b) { double tol 1e-12; double diff fabs(a - b); double scale fmax(fabs(a), fabs(b)); return diff tol * scale; }这段代码的意思是如果两个数的差值不超过两个数中较大那个的tol倍就认为它们相等。tol取1e-12时意思是大约 12 位有效数字一致对于双精度来说是比较合理的松紧度。但这个方法在a和b都接近 0 时又会失效因为scale接近 0任何微小的绝对差都会被放大成巨大的相对差。所以正规实现里通常要兜底先判断绝对误差再判断相对误差。int robust_equal(double a, double b) { double abs_tol 1e-12; double rel_tol 1e-12; double diff fabs(a - b); if (diff abs_tol) return 1; return diff rel_tol * fmax(fabs(a), fabs(b)); }我在项目里用的基本都是这种混合策略。先说结论没有任何一个比较函数是万能的你必须在理解数据物理意义的前提下选择比较策略。5. 从半精度到高精度不同浮点方案的工程选择5.1 浮点数 16 位工具FP16 到底能干什么网上搜索“浮点数16位工具”会指向各种 IEEE 754 在线转换工具以及 FP16 半精度格式。FP16 在嵌入式图形和深度学习领域被大规模使用结构也是 IEEE 754 那套只是位数更少符号 1 位、指数 5 位、尾数 10 位。它的最大有限值是 65504有效精度大约只有 3 位十进制。听起来很弱但在深度学习推理阶段权重和激活值的分布通常比较集中用 FP16 存可以省一半显存计算吞吐还更高。GPU 厂商后来还推出了 BF16 这种畸形选手指数位和 float32 一样多、尾数更少就是为了在不丢失范围的前提下做低精度计算。选哪种格式核心永远是在“范围”和“精度”之间做取舍。如果你需要做 16 位浮点数的调试我建议直接用 Python 的numpy.float16它会把所有转换和计算细节都暴露给你比手动查在线工具快得多import numpy as np x np.float16(0.1) y np.float16(0.2) print(x y) # 0.30005误差比 double 更大因为位数更少5.2 工业机器人里把 32 个输入定义为浮点数为什么这么常见热搜里出现“库卡机器人”和“将32个输入定义为浮点数”放在一起其实是工业现场的常见操作。库卡这类机器人控制器的编程环境里信号输入输出经常要声明为浮点数比如REAL类型就是 32 位浮点和 C 的float基本对应。机器人的关节角度、末端笛卡尔坐标、速度、加速度这些全是连续变化量用浮点数表达最自然。如果你把角度定义成整数转动 0.5 度就是一个长期存在的累积误差源。把 32 个输入定义为浮点数本质上是在建立“外部传感器 → 控制器变量”的映射。你可以把模拟量采到的电压、温度、压力直接映射到 32 个浮点变量里后续程序就能直接做浮点运算。这里要注意的依然是精度问题32 位浮点只有约 7 位有效十进制数如果机器人要处理亚毫米级定位有些中间计算结果在极端坐标下会损失精度。我见过有工程师在这种场景下坚持用“米”而不是“微米”做单位结果坐标插补始终差几个毫米排查了很久才发现是单位选择放大了浮点误差。工业控制里如果对精度敏感优先考虑把物理量换算到合适的量纲或者改用更高精度的数据类型。5.3 Julia 里的高精度浮点数和整数从根上解决取舍传统语言里想提高精度基本靠换double到long double但long double在不同平台实现不一样能保证的精度也很有限。真正从根上解决精度问题的思路变了改用任意精度类型。Julia 语言在这方面做得非常干净。它自带BigFloat和BigInt前者是任意精度浮点数后者是任意精度整数。写起来也很直观a BigFloat(0.1) b BigFloat(0.2) println(a b) # 0.3关键点是这里我把0.1作为字符串传进去Julia 会用十进制解析成高精度值而不是先转成二进制浮点再升精度。这就绕开了二进制不能精确表示 0.1 的问题。事实上任何语言只要你从字符串或十进制有理数出发做高精度运算都能得到符合直觉的结果。Julia 的BigInt更直接整数想多大就多大不会出现前面说的超过 2^53 后加 1 失效的问题。我做数值实验验证算法时经常先在 Julia 里用 BigFloat 算一遍基准值再回到 C 里写高性能版本。这种做法能快速确认误差是不是算法本身的锅而不是被浮点精度干扰了判断。不过代价也很现实BigFloat 的运算速度比原生 double 慢一两个数量级内存开销也大。所以工程上最理智的路线是先想清楚精度需求再决定用哪种类型而不是无脑上高精度。6. 实战避坑清单这些年我踩过的浮点坑6.1 先说一个最让我记忆犹新的坑有次我在做采集系统数据分析单位点计算的结果和理论值对不上。一开始怀疑是传感器标定问题后来怀疑是硬件滤波问题折腾了大半天最后发现是累加顺序造成误差偏大。代码原本是从第 1 个点累加到第 N 个点我改成从第 N 个点倒着累加到第 1 个点误差立刻小了一个数量级。这个案例让我彻底明白了浮点数相关的 bug 常常不会报错它只是安静地给你一个相差一点点但已经足够影响结论的值。排查时如果发现计算结果在末尾几位不稳定第一反应应该是检查运算顺序和舍入误差而不是怀疑硬件。6.2 什么时候千万别用浮点数浮点不是万能的。下面这些场景我建议直接绕开金额、账目用整数或十进制定点类型。货币面额本质是十进制二进制浮点存钱会出现 0.1 元加 0.2 元等于 0.30000000000000004 元的笑话精确计数、序号、ID超过 2^53 的整数别用 double需要精确哈希、位操作或精确相等的逻辑全部用整数类型时间戳的纳秒部分有些系统用 double 存 Unix 时间戳精度确实够到现在但到了未来或者要做纳秒级比较就会出问题需要稳定排序的关联键浮点数做哈希或字典键不同路径算出来的相同值可能不相等非常容易踩坑。反过来说物理量、采样值、坐标、科学计算这些天然带误差的连续量用浮点不仅没毛病反而是最合理的选择。6.3 一张表收尾浮点数高频问题速查场景推荐做法原因判断两个浮点数是否相等用相对误差加绝对误差兜底单纯受舍入误差影响大量浮点数求和优先倒序累加必要时用 Kahan 求和减少大数吃小数两个量级差距很大的数相加先归一化或重排计算顺序对阶时小数的有效位会丢失比较两个接近 0 的数绝对误差阈值优先相对误差此时会失真存储超过 2^53 的整数用 64 位整数或高精度整数库double 无法表示相邻整数工业控制里的距离/角度选择合适的单位量纲避免极端量级放大浮点误差深度学习推理考虑 FP16 或 BF16省显存、提吞吐精度通常够科学研究需要高可信基准用 Julia BigFloat 或 Python Decimal 算基准高精度结果可验证算法本身最后再分享一个我个人一直保留的习惯每次写完涉及浮点运算的模块我都会拿一组极端边界值去测比如非常大、非常小、接近 0、正负切换、连续做一万次运算后的结果。别觉得麻烦浮点数出错往往不是一次运算就翻车而是千百万次运算之后误差悄悄累积到不可接受那时候再排查成本高得会让你后悔没早点做测试。
