DigitList bug in recent patch (original) (raw)

Frank Ding dingxmin at linux.vnet.ibm.com
Wed Mar 27 07:50:32 UTC 2013

Current JDK gives the output of "78.0001".

Best regards, Frank

On 3/27/2013 3:48 PM, Frank Ding wrote:

Hi guys, We noticed there is a recent change (patch @ http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/bc1f16f5566f ) that changed the behavior of the following program.

import java.math.RoundingMode; public class TestNumberFormat { public static void main(String[] args) { java.text.NumberFormat numberFormat = java.text.NumberFormat.getInstance( java.util.Locale.US); double v = 78.00005; numberFormat.setMaximumFractionDigits(4); numberFormat.setRoundingMode(RoundingMode.HALFEVEN); numberFormat.setMinimumFractionDigits(0); numberFormat.setGroupingUsed(false); String ret = numberFormat.format(v); System.out.println(ret); } } Note the rounding mode HALFEVEN and the expected output should be "78" which can also be verified by running previous jdk (before b73). Stepping into code and the suspicious code is in DigitList.shouldRoundUp(). allDecimalDigits is false so true is returned, causing the last digit in fraction part to be 1. case HALFEVEN: // Implement IEEE half-even rounding if (digits[maximumDigits] > '5') { return true; } else if (digits[maximumDigits] == '5' ) { if (maximumDigits == (count - 1)) { // the rounding position is exactly the last index : if (alreadyRounded) // If FloatingDecimal rounded up (value was below tie), // then we should not round up again. return false; if (!allDecimalDigits) // Otherwise if the digits dont represent exact value, // value was above tie and FloatingDecimal truncated // digits to tie. We must round up. return true; Since I am not familiar of the numeric conversion, can any one shed your light on it? Best regards, Frank

More information about the core-libs-dev mailing list