Java 8 RFR 6476168: (fmt) Inconsistency formatting subnormal doubles with hexadecimal conversion
joe.darcy at oracle.com
Tue Jul 23 22:27:20 UTC 2013
This version looks fine; thanks,
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
>> you can just write
>> 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)
> on Mac OS 10.7.5.
More information about the core-libs-dev