为何f1与f2计算连续double值差值结果有时不一致？

首先明确：相邻两个可表示double值的差值（即ULP，最后一位单位）的标准正确计算方式是nextafter(num, INFINITY) - num，这个结果完全符合double二进制存储规则的真实差值。

可能的函数实现与错误点推测 #

根据你描述的现象，大概率是f1的实现逻辑存在错误，而f2的逻辑是正确的，具体分析如下：

1. double的存储规则与正确ULP计算

double是64位二进制浮点数，结构为：1位符号位 + 11位指数位 + 52位尾数位（隐含最高位的1，实际有效尾数为53位）。对于规格化的非零double值，相邻可表示数的差值（ULP）计算公式为2^(指数值 - 52)——这也是f2和nextafter结果一致的原因，说明f2正确实现了这个逻辑（比如通过frexp提取指数后用ldexp计算）。

2. f1出现1/2 ULP结果的常见错误

你的f1有时得到f2结果的1/2，常见原因有两种：

• 错误截断尾数小数部分：比如你把num乘以2^52后强制转成整数（截断小数），再加1转回double后求差。但很多十进制数（比如199.23999）无法精确转成double，乘以2^52后会带有小数部分，截断后得到的“下一个数”并不是真正的相邻可表示double，最终差值就会变成正确ULP的1/2。
• 指数计算错误：比如你错误地用指数值 - 53来计算增量，把隐含的最高位1也算进了存储的尾数位里——但存储的尾数位只有52位，最后一位的变化对应的增量是2^(指数-52)，而非2^(指数-53)。

3. 你认为f1正确的误区

你说“通过条件判断验证f1结果是真实差值”，大概率是验证方法出了问题：

• 很多十进制小数无法精确存储为double，比如199.23999实际存储的是一个近似的二进制值。如果用十进制打印来判断“最小变化”，由于打印精度限制（比如默认只打印6-7位有效数字），可能无法区分加ULP和加1/2 ULP的结果，误以为f1正确。
• 混淆了二进制浮点数的ULP和十进制的最小可分辨增量：double的相邻值差是基于二进制的，和十进制的位数没有直接关系，不能用十进制的最小变化来判断double的相邻差值。

内容的提问来源于stack exchange，提问作者AprilsBreeze