javascript - JavaScript 或 IEEE-754 中的舍入怪癖？

Question

我在我的一个单元测试中遇到了一个奇怪的问题，我在 JavaScript 中得到了意外的舍入结果:

(2.005).toFixed(2)
// produces "2.00"

(2.00501).toFixed(2)
// produces "2.01"

最初我怀疑这只是一个 Webkit 问题，但它在 Gecko 中重现，这对我来说意味着这是 ECMA-262 或 IEEE-754 的预期副作用。我假设 2.005 的二进制表示稍微少一点？或者 ECMA-262 是否为 toFixed 指定了舍入到偶数的方法？

有人愿意透露一些关于引擎盖下发生的事情的见解，只是为了让我安心吗？

更新:感谢您的评论。

我应该补充一点，让我有点紧张的一件事是在 Webkit dtoa.cpp 中快速搜索时发现的注释，这似乎暗示有多种舍入路径和开发人员并不确定它是如何工作的，包括相关的 FIXME:

https://trac.webkit.org/browser/trunk/Source/WTF/wtf/dtoa.cpp#L1110

此外，这并不是说它有什么意义，而是 IE9 按我的预期对其进行了舍入，暗示它不是 ECMA-262 的一部分，或者它们有一个错误。

Answer 1

如果规范自 Rev. 6 以来没有改变在 ECMA 262 草案(5.1 版，2011 年 3 月)中，(2.005).toFixed(2) 必须返回字符串 "2.00"，因为“数字值”是一个

primitive value corresponding to a double-precision 64-bit binary format IEEE 754 value

并且数字文字的解释在 7.8.3 和 8.5 中指定，以符合 IEEE 754“四舍五入到最近”模式(四舍五入到偶数)，这对于 2.005 导致值

x = 4514858626438922 * 2^(-51) = 2.00499999999999989341858963598497211933135986328125

在处理 toFixed 的 15.7.4.5 节中，相关步骤 8.a。是:

Let n be an integer for which the exact mathematical value of n ÷ 10^f – x is as close to zero as possible. If there are two such n, pick the larger n.

并且 2.00 - x 比 2.01 - x 更接近于零，所以这里的 n 必须是 200。然后以自然方式进行到字符串的转换。

Also, not that it means much but IE9 rounds it as I expected, implying that it either isn't part of ECMA-262 or they have a bug.

一个错误。也许他们试图走简单的路，用 10^digits 相乘并四舍五入。 x*100 恰好是 200.5，因此会产生一个字符串 "2.01"。