Hi Brian,
Almost there! A few additional comments.
On 7/22/2013 4:47 PM, Brian Burkhalter wrote:
An updated webrev is in the same location:
http://cr.openjdk.java.net/~bpb/6476168/.
On Jul 19, 2013, at 5:38 PM, Joseph Darcy wrote:
A spec quibble "decimal separator" isn't really the appropriate term for the
hex formatting.
I've changed this in the verbiage on lines 613 and 1376 of Formatter. The other usages of
"decimal separator" are unchanged.
I think some more test cases and needed:
* Subnormal result rounding up to normal range under reduced precision.
Something like nextDown(Double.MIN_NORMAL) (a subnormal value) rounded to
between 1 and 11 digits of precision.
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.
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.
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.
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.
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.
Thanks,
-Joe
Thanks,
Brian
