Go math.Expm1 为什么比 Exp(x)-1 更适合接近零的输入

在计算很小的增长率、概率增量或连续复利变化时，经常会遇到 e^x - 1。如果把它直接写成 math.Exp(x) - 1，当 x 接近零时，math.Exp(x) 也接近 1，最后一次减法可能把前面已经算出的有效数字抵消掉。Go 标准库提供的 math.Expm1(x) 就是为这个表达式准备的，接近零输入时应优先使用它。

官方说明地址：https://pkg.go.dev/math#Expm1

只要目标表达式是 e^x - 1，并且 x 可能很小，就把 math.Exp(x)-1 换成 math.Expm1(x)。它解决的是数值稳定性问题，不是通用的性能优化开关。

先把增长率场景缩小到一个表达式

假设服务要把一个很小的连续变化率转换成相对变化量，数学式是 e^x - 1。这时最直观的 Go 写法如下：

package main

import (
    "fmt"
    "math"
)

func main() {
    x := 1e-12 // 模拟接近零的连续变化率

    direct := math.Exp(x) - 1
    stable := math.Expm1(x)

    // 这里只比较两种表达式的结果，不把差异误认为业务精度证明。
    fmt.Printf("direct=%.18g stable=%.18g\\n", direct, stable)
}

问题在于浮点数的精度是有限的。对很小的 x，Exp(x) 的结果会先被舍入到一个非常接近 1 的数，再执行减法；这个减法的两个操作数数量级接近，部分有效数字就可能在相减时消失。这里的风险不是“指数函数算错了”，而是把一个小结果拆成了两个接近 1 的数再相减。

这也是为什么不能只看普通输入下的打印结果来判断写法：真正敏感的通常是极小输入、误差放大的后续计算，或者需要保留微小变化的累计逻辑。

把直接相减替换为 math.Expm1

math.Expm1 的签名是 func Expm1(x float64) float64，语义就是返回 e**x - 1。代码层面通常只需要替换调用点：

package main

import (
    "fmt"
    "math"
)

// relativeChange 把连续变化率转换为相对变化量。
func relativeChange(rate float64) float64 {
    // Expm1 直接表达 e^rate-1，避免先得到接近 1 的中间值。
    return math.Expm1(rate)
}

func main() {
    rate := 0.000000000001 // 业务输入可以来自配置、测量值或模型输出
    change := relativeChange(rate)

    // 结果交给后续业务逻辑；这里不把示例打印值当作精度基准。
    fmt.Printf("relative change: %.18g\\n", change)
}

选择这个函数的关键不是“写法更短”，而是让标准库使用针对 expm1 的数值实现。Go 的实现源码说明了它会进行参数缩减、近似计算和缩放处理，并明确把“接近零时比 Exp(x)-1 更准确”作为函数契约。

因此，代码审查时可以按表达式形态判断：如果业务真正需要的是 e^x，仍然使用 math.Exp；如果需要的是 e^x-1，尤其是小 x，使用 math.Expm1。

特殊值要按标准库契约处理

Expm1 并不是只对“小数”有效。官方文档列出了几个需要在边界测试或输入说明中保留的结果方向：

极大有限值还可能溢出到 +Inf，极小的负值则会逼近 -1。如果业务不允许这些结果，应在进入数学计算前定义输入约束，或者在计算后显式检查 math.IsNaN 与 math.IsInf，不要把它们静默转换成普通业务数值。

最后用四个问题做选择

• 目标是不是严格的 e^x-1？是，就优先考虑 math.Expm1。
• x 是否可能接近零？越接近零，直接相减的消减风险越值得避免。
• 后续是否要放大这个小变化？如果会，先保留稳定的中间结果，再做业务换算。
• 输入是否可能包含无穷大或 NaN？如果可能，先约定传播策略和错误处理。

相关问题：

• math.Expm1 会不会替代所有 math.Exp？不会。需要 e^x 本身时仍用 math.Exp。
• 只把 x 写成很小的常量就能验证精度吗？不能。它只能帮助构造边界样例，真实精度还要结合输入范围和业务误差预算。
• 为什么不能用普通减法补救？因为误差发生在中间值舍入和相近数相减的组合中，换一种减法顺序并不能表达专用算法。