我知道 float 学充其量是丑陋的，但我想知道是否有人可以解释以下怪癖。在我测试的大多数编程语言中，将 0.4 添加到 0.2 会产生轻微错误，而 0.4 + 0.1 + 0.1 则不会。
两者计算不等的原因是什么，以及在各自的编程语言中可以采取哪些措施来获得正确的结果。
在python2/3中
.4 + .2
0.6000000000000001
.4 + .1 + .1
0.6
同样的情况发生在 Julia 0.3
julia> .4 + .2
0.6000000000000001
julia> .4 + .1 + .1
0.6
和斯卡拉:
scala> 0.4 + 0.2
res0: Double = 0.6000000000000001
scala> 0.4 + 0.1 + 0.1
res1: Double = 0.6
和 Haskell:
Prelude> 0.4 + 0.2
0.6000000000000001
Prelude> 0.4 + 0.1 + 0.1
0.6
但是 R v3 做对了:
> .4 + .2
[1] 0.6
> .4 + .1 + .1
[1] 0.6
最佳答案
所有这些语言都使用系统提供的浮点格式，它以二进制而不是十进制表示值。 0.2 和 0.4 之类的值无法以该格式精确表示，因此存储了最接近的可表示值，从而导致小错误。例如，数字文字 0.2 会产生一个 float ，其精确值为 0.200000000000000011102230246251565404236316680908203125。类似地，对 float 的任何给定算术运算都可能导致无法精确表示的值，因此将真正的数学结果替换为最接近的可表示值。这些是您所看到的错误的根本原因。
但是，这并不能解释语言之间的差异:在您的所有示例中，都进行了完全相同的计算并得出了完全相同的结果。不同之处在于各种语言选择显示结果的方式。
严格来说，没有一个您给出的答案是正确的。使用四舍五入模式对 IEEE 754 二进制 64 算法进行(相当安全)假设，第一个和的确切值为:
0.600000000000000088817841970012523233890533447265625
而第二个总和的确切值为:
0.59999999999999997779553950749686919152736663818359375
但是，这些输出都不是特别用户友好的，而且很明显，您测试的所有语言都做出了在打印时缩写输出的明智决定。但是，它们并非都采用相同的策略来格式化输出，这就是您看到差异的原因。
有许多可能的格式化策略，但三种特别常见的策略是:
计算并显示 17 个正确舍入的有效数字，可能会去除它们出现的尾随零。 17 位的输出保证了不同的 binary64 float 将具有不同的表示，因此可以从其表示中明确地恢复浮点值； 17 是具有此属性的最小整数。例如，这就是 Python 2.6 使用的策略。
计算并显示在通常舍入到偶数舍入模式下舍入到给定 binary64 值的最短十进制字符串。这比策略 1 实现起来要复杂得多，但保留了不同的 float 具有不同表示的属性，并且倾向于产生更愉快的输出。这似乎是您测试的所有语言(R 除外)都在使用的策略。
计算并显示 15 个(或更少)正确舍入的有效数字。这具有隐藏十进制到二进制转换中涉及的错误的效果，给人一种精确十进制算术的错觉。它的缺点是不同的 float 可以具有相同的表示。这似乎是 R 正在做的事情。 (感谢@hadley 在评论中指出 R setting 控制用于显示的位数；默认使用 7 位有效数字。)
关于python - 不同编程语言中的 float 学，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/21872854/