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 <hbo...@google.com
<mailto:hbo...@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.da...@oracle.com
<mailto:joe.da...@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.da...@oracle.com
<mailto:joe.da...@oracle.com><mailto:joe.da...@oracle.com
<mailto:joe.da...@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.
