Java 8 RFR 6476168: (fmt) Inconsistency formatting subnormal doubles with hexadecimal conversion

Joseph Darcy joe.darcy at
Tue Jul 23 01:13:01 UTC 2013

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:
> 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


you can just write


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,
> Brian

More information about the core-libs-dev mailing list