Go math.Log2 在 1 附近为什么误差会被放大：浮点消减与跨平台结果边界

同一段 Go 代码在 amd64 和 arm64 上计算 math.Log2(math.Nextafter(1, 2))，结果可能不完全相同。这里真正需要警惕的不是最后几位不同，而是输入极接近 1 时发生浮点消减：真实结果本来就很小，一点中间舍入会被相对误差放大。

Go 官方 issue #81121 给出的样例中，参考值约为 3.203426503814917e-16，而不同平台上的 math.Log2 结果出现约 4% 到 14.9% 的相对偏差。绝对误差仍小，但对依赖相对精度的数值算法已经值得单独处理。

先确认问题是否落在 x≈1 的消减区间

先保留原始输入、Go 版本、GOARCH 和完整结果，再用同一输入计算两个表达式。math.Nextafter(1, 2) 是比 1 大的下一个 float64，很适合暴露这个边界：

x := math.Nextafter(1, 2)
direct := math.Log2(x)
reference := math.Log1p(x-1) / math.Ln2

fmt.Printf("x=%.17g direct=%.18g reference=%.18g\n", x, direct, reference)

这里要同时看绝对误差和相对误差。结果量级约为 10^-16 时，即使差值看起来只有小数末尾的一点变化，除以参考值后也可能变成几个百分点。若普通区间稳定、偏差只聚集在 1 的相邻浮点数附近，才与这次问题吻合。

拆开 Frexp、Log 与加法，找到有效位损失

math.Log2 的相关实现会先通过 Frexp 把输入拆成小数部分和指数。对输入 x≈1，可能得到 frac≈0.5 与指数 1；随后计算 Log(frac)，乘上 1/math.Ln2，再与指数相加。

风险就在最后一次加法：乘积非常接近 -1，指数项是 1，两者大小接近、符号相反。相减后得到小结果，前面舍入掉的低位却不会回来，这就是灾难性消减。判断标准很直接：若中间量都接近 1，而最终值比它们小十几个数量级，就不能只用“绝对差很小”来判断精度。

区分 amd64 舍入与 arm64 FMA 的结果差异

amd64 常见路径可能先对乘法结果做一次中间舍入，再完成加法；arm64 则可能把乘法和加法融合为 FMA，只在末尾舍入一次。通常 FMA 能减少舍入次数，但在这个消减点，两条路径保留的低位不同，所以最终的小结果也会不同。

这不等于“arm64 一定更错”或“amd64 一定正确”。Go 的浮点表达式不应被默认理解为跨架构逐位一致。业务若把计算结果写入哈希键、快照或跨节点一致性判断，应该先定义容差或统一算法路径；普通统计展示则往往只需记录差异，不必贸然替换全部 math.Log2 调用。

用 Log1p 建立替代写法与回归边界

math.Log1p 专门计算 log(1+y)，当 y 很小时能避免先形成一个舍入后的 1+y。因此，对确实关心 1 附近相对精度的局部代码，可以评估 math.Log1p(x-1) / math.Ln2。这是一种应用层策略，不代表 Go 标准库已经采用了 issue 中讨论的修复。

不要把替代式无条件铺到所有输入。更稳妥的做法是先定义区间，再让 math.Log2 负责普通范围，让 math.Log1p(x-1) 只覆盖经过验证的近 1 区间。回归用例至少包含 1 两侧的相邻浮点数、普通正数、2 的幂，以及零、负数、无穷和 NaN；amd64 与 arm64 都要按同一容差规则检查。

常见问题

这是不是说明 math.Log2 不能使用？

不是。问题集中在非常接近 1、且业务关心相对精度的边界。普通输入仍应优先使用标准库函数，避免为一个窄区间增加全局复杂度。

比较两个结果时可以直接使用 == 吗？

跨平台数值计算通常不适合依赖逐位相等。应根据结果量级和业务后果定义绝对容差、相对容差，必要时再检查 ulp。

Log1p 写法已经是 Go 官方修复吗？

不是。它是官方 issue 中讨论并给出测试数据的建议方向；在 issue 关闭、变更进入发布说明前，都应视为待验证方案。

排查这类问题时，最关键的是先缩小输入区间，再拆中间量，最后才比较平台。这样既能看到浮点消减的真正来源，也不会把所有末位差异误诊成同一个标准库缺陷。