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 一直保持定义不变。