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

[Brian Burkhalter]

I think that sounds good.

Brian

On Aug 22, 2016, at 2:44 PM, Hans Boehm <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> 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.