JDK 9 RFR of JDK-8164524: Correct inconsistencies in floating-point abs spec

[Hans Boehm]

The new version seems less clear to me. Could it be misread as only
applying if the value is positive? s/of/indicating a/ ?


On Mon, Aug 22, 2016 at 1:47 PM, Joseph D. Darcy <joe.darcy at oracle.com>
wrote:

> Hello,
>
> I plan to push with a slightly different wording. Rather than
>
>     ... but with a guaranteed positive sign bit:
>
> using
>
>     ...but with a guaranteed zero sign bit of a positive value:
>
> I think the latter is clearer.
>
> Thanks,
>
> -Joe
>
> On 8/22/2016 11:41 AM, Brian Burkhalter wrote:
>
>> Hi Joe,
>>
>> This doc-only patch appears reasonable to me. Approved.
>>
>> Brian
>>
>> On Aug 20, 2016, at 11:55 AM, joe darcy <joe.darcy at oracle.com <mailto:
>> joe.darcy at oracle.com>> wrote:
>>
>> Please review the doc-only patch below to address
>>>
>>>    JDK-8164524: Correct inconsistencies in floating-point abs spec
>>>
>>> In brief, Martin noted in JDK-8164199 that a close reading of the
>>> specification of the Math and StrictMath floating-point abs methods reveals
>>> some inconsistencies in the text of the specification versus the
>>> operational semantics of the sample code in term of NaN handling.
>>>
>>> To resolve this, the sample code is slightly modified and demoted to
>>> informative rather than normative text.
>>>
>>> The core of the edit is changing
>>>
>>>    Float.intBitsToFloat(0x7fffffff & Float.floatToIntBits(a))
>>>
>>> to
>>>
>>>    Float.intBitsToFloat(0x7fffffff & Float.floatToRawIntBits(a))
>>>
>>> that is the "raw" floating-point => integral conversion rather than the
>>> "cooked" one which has tighter behavioral requirements around different NaN
>>> values, analogous changes for the double cases.
>>>
>>
>>
>