From: the.codefolio.guy@... Date: 2016-08-16T16:26:09+00:00 Subject: [ruby-core:76936] [Ruby trunk Bug#12548] Rounding modes inconsistency between round versus sprintf Issue #12548 has been updated by Noah Gibbs. It looks like floats are rounded via numeric.c, using the flo_round function. That definitely does *not* use round-even. Maybe it should? It already implements a rounding function, so it shouldn't be too hard to implement round-even. It looks like sprintf uses ruby_sprintf, through a series of calls to BSD_vfprintf in vsnprintf.c. At least on my machine. And BSD_vprintf winds up calling ruby_dtoa (#defined from BSD__dtoa) with mode 3. If you look for "round-even" in util.c, you'll see an extensive comment explaining why they used round-even mode. So basically: right now, Numeric#round uses flo_round(), while sprintf uses util.c's round-even mode. Presumably we should change flo_round to do round-even. ---------------------------------------- Bug #12548: Rounding modes inconsistency between round versus sprintf https://bugs.ruby-lang.org/issues/12548#change-60165 * Author: Kieran McCusker * Status: Open * Priority: Normal * Assignee: * ruby -v: 2.3.1 * Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN ---------------------------------------- Hi I've found this possible bug with sprintf in our production code, but it seems very odd that no one has reported it so I'm doubting myself. I've tested a few versions (CRuby 2.3.1 and 2.1.9) and it was present in both. To reproduce in irb: sprintf('%1.0f', 12.5) Expected result 13 actual 12 In fact if you look at the number sequence 0.5 -> 99.5 you find the even half will all round down and the odd half round up. 12.5.round produces the correct result (13) If you do the same in jruby 2.2.1 you get the expected result of 13. Many thanks Kieran -- https://bugs.ruby-lang.org/ Unsubscribe: