Golang 浮点精度 float32 与 float64

Question

我写了一个程序来演示 Go 中的浮点错误：

func main() {
    a := float64(0.2) 
    a += 0.1
    a -= 0.3
    var i int
    for i = 0; a < 1.0; i++ {
        a += a
    }
    fmt.Printf("After %d iterations, a = %e\n", i, a)
}

打印出来：

After 54 iterations, a = 1.000000e+00

这与用 C 编写的同一程序的行为相匹配（使用 double 类型）

但是，如果改用float32，程序就会陷入无限循环！如果您修改 C 程序以使用 float 而不是 double，它会打印

After 27 iterations, a = 1.600000e+00

为什么Go程序在使用float32时输出与C程序不同？

Answer 1

使用 math.Float32bits 和 math.Float64bits，您可以看到 Go 如何将不同的十进制值表示为 IEEE 754 二进制值：

游乐场：https://play.golang.org/p/ZqzdCZLfvC

结果：

float32(0.1): 00111101110011001100110011001101
float32(0.2): 00111110010011001100110011001101
float32(0.3): 00111110100110011001100110011010
float64(0.1): 0011111110111001100110011001100110011001100110011001100110011010
float64(0.2): 0011111111001001100110011001100110011001100110011001100110011010
float64(0.3): 0011111111010011001100110011001100110011001100110011001100110011

如果您将convert these 二进制表示为十进制值并执行循环，您可以看到对于 float32，a 的初始值将是：

0.20000000298023224
+ 0.10000000149011612
- 0.30000001192092896
= -7.4505806e-9

一个永远不会等于 1 的负值。

那么，为什么 C 的行为会有所不同？

如果您查看二进制模式（并且稍微了解如何表示二进制值），您会发现 Go 会舍入最后一位，而我假设 C 只是裁剪它。

因此，从某种意义上说，虽然 Go 和 C 都不能准确地表示浮点数中的 0.1，但 Go 使用最接近 0.1 的值：

Go:   00111101110011001100110011001101 => 0.10000000149011612
C(?): 00111101110011001100110011001100 => 0.09999999403953552

编辑：

我发布了a question about how C handles float constants，从答案看来，C 标准的任何实现都允许这样做。您尝试使用的实现与 Go 不同。

Answer 2

同意 ANisus，go 是在做正确的事。关于 C，我不相信他的猜测。

C 标准没有规定，但 libc 的大多数实现会将十进制表示转换为最接近的浮点数（至少符合 IEEE-754 2008 或 ISO 10967），所以我认为这不是最可能的解释.

C 程序行为可能不同的原因有多种...尤其是，某些中间计算可能会以超高的精度（双精度或长双精度）执行。

我能想到的最可能的事情是，如果你曾经在 C 中写过 0.1 而不是 0.1f。
在这种情况下，您可能会导致初始化精度过高
（你 sum float a+double 0.1 => float 转换为 double，然后 result 转换回 float）

如果我模拟这些操作

float32(float32(float32(0.2) + float64(0.1)) - float64(0.3))

然后我在 1.1920929e-8f 附近找到了一些东西

27 次迭代后，总和为 1.6f