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

[Brian Burkhalter]

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