RE: Urgent [9] RFR (S) : JDK-8039915 NumberFormat.format() does not consider required no. of fraction digits properly
Hi Oliver,
First, sorry about mistyping your name, Olivier!
I copied your patch into my shim locally and ran my test cases and still get a couple failures (see output below). Your patch and my version differ in the way and order in which we interpret allDecimalDigits and alreadyRounded.
And I should have been more diligent. On second look these are all "very close to a tie" as described in JDK-7131459, so I now believe my test suite is incorrect. It matched the JDK 6-7 behavior but did not account for the JDK8 intended changes for these edge cases. JDK-7131459 test case: 0.15 is actually: 0.1499999999999999944488848768742172978818416595458984375 HALF_UP --> 0.1 OK 0.35 is actually: 0.34999999999999997779553950749686919152736663818359375 HALF_UP --> 0.3 OK 0.85 is actually: 0.84999999999999997779553950749686919152736663818359375 HALF_UP --> 0.8 OK 0.95 is actually: 0.9499999999999999555910790149937383830547332763671875 HALF_UP --> 0.9 OK Above tests used Java 1.8.0_20 (Oracle Corporation) installed at C:\JAVA\latest8\jre Agent installed: yes Patch applied : yes Overall result : FIXED -- William Price | Software Architect | PROS, Inc.
Hi William, Thanks a lot for your time and checks ! On 19/09/2014 22:02, William Price wrote:
Hi Oliver, First, sorry about mistyping your name, Olivier!
I copied your patch into my shim locally and ran my test cases and still get a couple failures (see output below). Your patch and my version differ in the way and order in which we interpret allDecimalDigits and alreadyRounded. And I should have been more diligent. On second look these are all "very close to a tie" as described in JDK-7131459, so I now believe my test suite is incorrect. It matched the JDK 6-7 behavior but did not account for the JDK8 intended changes for these edge cases. Yes these are voluntarily all tricky cases with dtoa() returning an exact tie due to IEEE-754 precision limit, thus following nearest to even policy and either rounding up or truncating right at the rounding digit position.
allDecimalDigits indicates whether dtoa() was able to provide all the exact digits, with result still inside IEEE-754 precision. alreadyRounded indicates whether the result was truncated or rounded up. I think allDecimalDigits must be checked first, followed by alreadyRounded, since if you get an exact binary representation within IEEE precision, dtoa won't do any rounding by principle. I believe the latest (last Friday) version of your patch on github is ok. Thanks again William for following this bug, and for the feedback and checking of the patch for this review ! Best Regards, Olivier.
JDK-7131459 test case: 0.15 is actually: 0.1499999999999999944488848768742172978818416595458984375 HALF_UP --> 0.1 OK 0.35 is actually: 0.34999999999999997779553950749686919152736663818359375 HALF_UP --> 0.3 OK 0.85 is actually: 0.84999999999999997779553950749686919152736663818359375 HALF_UP --> 0.8 OK 0.95 is actually: 0.9499999999999999555910790149937383830547332763671875 HALF_UP --> 0.9 OK
Above tests used Java 1.8.0_20 (Oracle Corporation) installed at C:\JAVA\latest8\jre
Agent installed: yes Patch applied : yes
Overall result : FIXED
participants (2)
-
olivier.lagneau＠oracle.com
-
William Price