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
