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

[Joseph D. Darcy]

Pushed with suggested wording change; thanks,

-Joe

On 8/22/2016 3:24 PM, Brian Burkhalter wrote:
> I think that sounds good.
>
> Brian
>
> On Aug 22, 2016, at 2:44 PM, Hans Boehm <hboehm at google.com 
> <mailto:hboehm at google.com>> wrote:
>
>> 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 
>> <mailto: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><mailto: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.
>>
>