为什么 Ruby 的 Float#round 行为与 Python 不同？

总结

这两种实现都面临着围绕二进制浮点数s 的相同问题。

Ruby 通过简单的操作（乘以 10 的幂、调整和截断）直接对浮点数进行操作。

Python 使用 David Gay 的复杂算法将二进制浮点数转换为字符串，该算法产生与二进制浮点数完全相等的最短十进制表示形式。这不会进行任何额外的舍入，而是精确转换为字符串。

有了最短的字符串表示形式，Python 就会使用精确的字符串运算将四舍五入到适当的小数位数。浮点数到字符串转换的目标是尝试“撤消”一些二进制浮点表示错误（即，如果您输入 6.6，Python 会在 6.6 上四舍五入，而不是 6.59999999999999999996。

此外，Ruby 在舍入模式上与某些版本的 Python 不同：从零开始舍入与舍入半偶数。

细节

Ruby 不作弊。它以普通的旧二进制浮点数开头，就像 Python 一样。因此，它受到一些相同的挑战（例如3.35略高于3.35,4.35略低于4.35）：

>>> Decimal.from_float(3.35)
Decimal('3.350000000000000088817841970012523233890533447265625')
>>> Decimal.from_float(4.35)
Decimal('4.3499999999999996447286321199499070644378662109375')

查看实现差异的最佳方法是查看底层源代码：

下面是 Ruby 源代码的链接： https://github.com/ruby/ruby/blob/trunk/numeric.c#L1587

Python 源代码从这里开始：http://hg.python.org/cpython/file/37352a3ccd54/Python/bltinmodule.c，到这里结束：http://hg.python.org/cpython/file/37352a3ccd54/Objects/floatobject.c#l1080

后者有广泛的注释，揭示了两种实现之间的差异：

基本思想非常简单：将 double 转换并四舍五入为 十进制字符串_Py_dg_dtoa，然后转换该十进制字符串 回到_Py_dg_strtod的双打。有一个小困难： Python 2.x 期望 round 执行 round-half-away-from-0，而 _Py_dg_dtoa做四舍五入到偶数。因此，我们需要一些方法来检测和纠正中途情况。

检测：中途值的格式为 k * 0.5 * 10**-ndigits 一些奇数整数 k。或者换句话说，一个有理数 x 正好是 介于 10**-ndigits 的两个倍数之间，如果其 2 估值为 正好是 -ndigits-1，它的 5 估值至少是 -ndigits。对于 ndigits >= 0，二进制浮点数 x 会自动满足后一个条件，因为任何这样的浮点数都具有非负数 5-估值。对于 0 > ndigits >= -22，x 需要是积分 5**-ndigits 的倍数;我们可以使用 fmod 来检查这一点。适用于 -22 > ndigits，没有中间情况：5**23 需要 54 位来表示 没错，所以 n >= 23 的任何 0.5 * 10**n 的奇数倍至少需要 精确表示 54 位精度。

更正：处理中途情况的一个简单策略是 （仅适用于中途情况）调用 _Py_dg_dtoa 的参数为 ndigits+1 而不是 ndigits（因此精确转换为 decimal），手动舍入生成的字符串，然后转换回 使用_Py_dg_strtod。

简而言之，Python 2.7 竭尽全力准确地遵循从零开始四舍五入的规则。

在 Python 3.3 中，精确遵循四舍五入规则的长度同样长。

以下是有关_Py_dg_dtoa功能的一些额外细节。Python 调用 float to string 函数，因为它实现了一种算法，该算法在相等的替代方案中提供尽可能短的字符串表示形式。例如，在 Python 2.6 中，数字 1.1 显示为 1.100000000000000001，但在 Python 2.7 及更高版本中，它只是 1.1。David Gay 复杂的 dtoa.c 算法在不牺牲准确性的情况下提供了“人们期望的结果”。

该字符串转换算法倾向于弥补困扰二进制浮点数上 round（） 的任何实现的一些问题（即，4.35 的舍入较少，从 4.35 开始，而不是 4.349999999999999999447286321199499070644378662109375）。

这和舍入模式（舍入-半偶数与舍入-从零开始）是 Python 和 Ruby round（） 函数之间的本质区别。

根本区别在于：

Python：转换为十进制，然后四舍五入

Ruby：四舍五入，然后转换为十进制

Ruby 从原始浮点位字符串对其进行四舍五入，但在对它进行 10ⁿ 操作之后。如果不仔细观察，就无法看到原始二进制值。这些值是不精确的，因为它们是二进制的，而且我们习惯于用十进制书写，碰巧的是，我们可能编写的几乎所有十进制分数字符串都没有与以 2 为基数的分数字符串完全等价。

具体而言，0.45 如下所示：

01111111101 1100110011001100110011001100110011001100110011001101 

在十六进制中，这是3fdccccccccccccd.

它以二进制形式重复，第一个未表示的数字是，巧妙的十进制输入转换已准确地将最后一个小数四舍五入为 .0xc,0xd

这意味着在机器内部，该值大约大于 1/2⁵⁰。这显然是一个非常非常小的数字，但它足以导致默认的四舍五入算法四舍五入，而不是偶数的决胜局。0.45

Python 和 Ruby 都可能四舍五入不止一次，因为每个操作都有效地四舍五入到最低有效位。

我不确定我是否同意 Ruby 会做人类会做的事情。我认为 Python 正在近似于十进制算术的作用。Python（取决于版本）将 round-nearest 应用于十进制字符串，而 Ruby 将 round nearest 算法应用于计算出的二进制值。

请注意，我们可以在这里非常清楚地看到人们说 FP 不准确的原因。这是一个相当正确的陈述，但更真实的是，我们根本无法在二进制和大多数十进制分数之间准确转换。（有些是：0.25、0.5、0.75......大多数简单的十进制数都是二进制中的重复数字，因此我们永远无法存储确切的等效值。但是，我们可以存储的每个值都是确切已知的，并且对其执行的所有算术操作都是精确执行的。如果我们首先用二进制写分数，我们的 FP 算术将被认为是准确的。

Ruby 不作弊。它只是选择了另一种实现 round 的方式。

在 Ruby 中，几乎等同于 .9.45.round(1)(9.45*10.0).round / 10.0

irb(main):001:0> printf "%.20f", 9.45
9.44999999999999928946=> nil
irb(main):002:0> printf "%.20f", 9.45*10.0
94.50000000000000000000=> nil

所以

irb(main):003:0> puts 9.45.round(1)
9.5

如果我们在 Python 中使用这种方式，我们也将获得 9.5。

>>> round(9.45, 1)
9.4
>>> round(9.45*10)/10
9.5