Hi Brian,
This version looks fine; thanks,
-Joe
On 7/23/2013 12:09 PM, Brian Burkhalter wrote:
Hi Joe,
The webrev http://cr.openjdk.java.net/~bpb/6476168/ is updated per the
following.
On Jul 22, 2013, at 6:13 PM, Joseph Darcy wrote:
The changes in that block include
1353 // 6476168: subnormal formatting and precision
It is not customary, and usually not desirable, to include the bug id.
Additionally, the new block of test cases tests for subnormal as well as
underflow the comment is not accurate.
Comment expunged.
It is not necessary to write
Double.parseDouble("0x0.123p-1022")
you can just write
0x0.123p-1022
using the hexadecimal notation for a floating-point literal.
Changed in the cases I added and in the preexisting cases.
I'd like to see a few more test cases that probe at boundaries, such as
Double.MAX_VALUE rounding to 9, 6, 2, 1, digits of precision.
Please see lines 1372-1379 of Basic-X.
There are also cases of interest to make sure the round to nearest even
rounding policy is being used. If a value like 0.123xxxxxxxxxxxx is rounded to
three digits, the value of xxxxxxxxxxxx will determine whether or not an
increment occurs.
Please see lines 1355-1368 of Basic-X.
Added as Basic-X line 1360.
* Double.MAX_VALUE rounded to fewer than 12 digits. Offhand, I'm not sure what
the implementation will do here; returning infinity or a hex string with an
extra big exponent are both defensible.
Added as Basic-X line 1361. The returned value for %1.9a is 0x1.000000000p1024.
Of the two options, that value is preferable.
Interestingly the C stdio library
printf("%1.9a\n", 1.7976931348623157e+308)
prints
0x2.000000000p+1023
on Mac OS 10.7.5.
Thanks,
Brian
