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

[Joe Darcy]

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