I think that sounds good. Brian
On Aug 22, 2016, at 2:44 PM, Hans Boehm <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> 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>> 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.
