Issue #12958 has been updated by mathew murphy.


For the record, I think that the new choice of default is poor. 

People have a normal everyday expectation for how numbers are rounded. I claim that the expectation is that >= .5 rounds up, <.5 rounds down. 

I cite as evidence:

 * It's the rule required by the [US Internal Revenue Service][irs].
 * It's [the behavior of Math.round() in JavaScript][js].
 * It's the behavior of the [C standard library round() function][c] as [required by POSIX][posix].
 * It's the behavior of [Math.round in Java][java].
 * It's the default behavior of PHP.
 * It's the default [for Perl][perl].
 * It's the behavior for [Swift][swift].
 * It's [what MATLAB does][matlab].
 * It's what [SQL does][sql].
 * It's what [COBOL does][cobol].
 * It's what [Rust does][rust].

It's also what I was taught throughout school, until I studied computer science and bookkeeping and learned about banker's rounding and statistical bias and other advanced topics.

So in keeping with the principle of least surprise, I think the default for #round should be to do what the man on the street would expect, and what programmers used to almost every other programming language would expect.

In checking all the most popular programming languges, I can find only three examples which do round-to-even by default: Python, R, and Visual BASIC. VB [notes][vb] that "Rounding away from zero is the most widely known form of rounding". R is infamously user-hostile.

Fun sidenote: When Go discussed adding a `round` method, [the comment was made][go] "It's not obvious to me that TiesToEven is useful in the context of integral rounding."  I agree with this. I have _literally never_ needed round-to-even for floating point. Yes, it eliminates consistent bias in financial rounding, but _nobody should be using floats for financial data to start with_.

My feeling is that the rounding behavior of `sprintf` is unexpected and should be documented; and given that it's documented, it's unnecessary and unexpected for the rest of Ruby to conform to `sprintf`'s behavior and not to POSIX.

[irs]: https://www.irs.gov/instructions/i1042s/ch02.html#d0e2824
[js]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/round
[c]: http://www.gnu.org/software/libc/manual/html_node/Rounding-Functions.html
[java]: https://docs.oracle.com/javase/7/docs/api/java/lang/Math.html#round(float)
[go]: https://github.com/golang/go/issues/4594
[vb]: https://msdn.microsoft.com/en-us/library/system.math.round(v=vs.110).aspx#Midpoint
[perl]: http://search.cpan.org/dist/Math-Round/Round.pm
[swift]: https://developer.apple.com/reference/swift/floatingpoint/2297801-round
[matlab]: https://www.mathworks.com/help/matlab/ref/round.html?requestedDomain=www.mathworks.com
[sql]: https://docs.oracle.com/cd/B19306_01/server.102/b14200/functions135.htm
[cobol]: http://www.ibm.com/support/knowledgecenter/SS6MTS_7.1.1/com.ibm.websphere.ilog.cobol.doc/Content/Business_Rules/Documentation/_pubskel/JRules_COBOL/ps_rules_for_cobol85.html
[rust]: https://doc.rust-lang.org/1.6.0/std/primitive.f64.html
[posix]: http://pubs.opengroup.org/onlinepubs/009695399/functions/round.html

----------------------------------------
Bug #12958: Breaking change in how `#round` works
https://bugs.ruby-lang.org/issues/12958#change-61943

* Author: Rafael Fran├ža
* Status: Assigned
* Priority: Normal
* Assignee: Kenta Murata
* ruby -v: 
* Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
We noticed in the Rails test suite that there is a breaking change in how `#round` works between 2.3 and 2.4

https://github.com/rails/rails/pull/27091

Is that desirable?

I think it is may cause a lot of problem if the behavior of `#round` without any arguments changes between a minor version.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>