转载

round 函数在不同语言中的实现乱象

以前曾经写过一篇小文四舍五入？并不准确，介绍了 rounding 功能在遇到类似 2.5, 3.5 等小数部分恰好是半数的时候，并不遵循我们更熟悉的“四舍五入”，而是采用“奇进偶舍”，或者叫做“四舍六入五成双”的规则，英文叫做 Banker's rounding.

在那篇文章中，我以 Python 为例，round(2.5) 取值为 2, 而 round(3.5) 取值为 4. 而最近我才发现，这里我写得不对，各种语言的实现很乱，而 Python 2 和 3 竟然是不一致的.

对于 rounding half 的规则，有很多种实现方式：

round half up：向正无穷大进位，round(2.5) 为 3, 而 round(-2.5) 为 -2, Java 的 Math.round 采用这个规定
round half down: 向负无穷大进位
round half towards zero: 向 0 进位, round(2.5) 为 2, 而 round(-2.5) 为 -2
round half away from zero: 远离 0 进位, C 语言的库函数 round 是此规则, Python 2 和 JavaScript 等多种语言也采用的是这一规则.
round half to even: 向偶数进位，即之前介绍过的 Banker's rounding，在统计学上有更好的效果，浮点数的标准 IEEE 754 默认采用此规则，Python 3 也选择了它作为新规则
round half to odd: 和上面相反，向奇数进位，在计算机中几乎没有被用到
随机 round: 统计学中更实用，但编程语言的实现不可能采用此规则

还有的语言提供多种实现，比如 Ruby 默认用的是 round half away from zero，但也提供了 :even 和 :odd 的选项。

简直太乱了，和对负数的取模运算有的一拼。我个人猜测可能是由于很多语言沿袭了 C 语言的规则，而 IEEE 754 作为浮点数的标准，又比 C 语言诞生得晚。这两种成为了最广泛采用的规则，至于为什么 Java 选择了不走寻常路，就不得而知了。

C 语言后来也提供了相关的宏定义，以支持不同规则，但库函数的 round 一直保持定义不变。

round 函数在不同语言中的实现乱象

原文 https://mp.weixin.qq.com/s?__biz=MzAwNzkzOTkzMQ==&mid=2247484058&idx=1&sn=15c0f19b792aef8eb0373b05ce10583f&chksm=9b7730aeac00b9b8868106c66b957d18df2a764f186d128377189ebf4bbbe08ff7573f4e48a6&token=1613963966&lang=zh_CN

正文到此结束