Fwd: JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs

Joe Darcy joe.darcy at oracle.com
Tue Jul 22 16:52:49 UTC 2014


Hello Georgiy,

On 07/22/2014 08:35 AM, Georgiy Rakov wrote:
> Hello Joe,
>
> if I understand correctly the doc doesn't specify exact circumstances 
> leading to infinities, it just has general assertion:
>
>      * <li>If the recorded values contain one or more infinities, the
>      * sum will be infinite or NaN.
>
> this assertion is clarified by following child assertions which 
> specify just NaN-causing circumstances but what exactly can lead to 
> infinities is not specified therein:
>
>      * <ul>
>      *
>      * <li>If the recorded values contain infinities of opposite sign,
>      * the sum will be NaN.
>      *
>      * <li>If the recorded values contain infinities of one sign and
>      * an intermediate sum overflows to an infinity of the opposite
>      * sign, the sum may be NaN.
>
> I believe that some details should be provided clarifying how exactly 
> +/- infinities can be resulted from input (as I see it this cannot be 
> inferred from the provided doc); otherwise I'm afraid this won't be 
> testable from conformance point of view.

It should not be the role of this method's specification to provide a 
full tutorial on IEEE floating-point arithmetic.

Overflow to infinity can occur when adding up just two floating-point 
values; the sum being equal to just one of the operands can occur too.

I don't think is is helpful or appropriate to spell all that out for 
this sum method. The JLS material describing floating-point in Java is 
implicitly assumed:

http://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.2.3
http://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.2.4

Cheers,

-Joe

>
> Thank you,
> Georgiy.
>
> On 22.07.2014 7:33, Joe Darcy wrote:
>> On 07/18/2014 12:00 PM, Georgiy Rakov wrote:
>>>
>>> On 18.07.2014 20:14, Joe Darcy wrote:
>>>> Hello Georgiy,
>>>>
>>>> On 07/18/2014 05:29 AM, Georgiy Rakov wrote:
>>>>> Hello Joe,
>>>>>
>>>>> could you please clarify by short example following assertion:
>>>>>
>>>>>   154      * If the exact sum is infinite, a properly-signed infinity is
>>>>>   155      * returned.
>>>>>
>>>>> I'm afraid I don't quite understand what you mean here by 'exact sum'.
>>>>
>>>> By "exact sum," the sum absent any floating-point rounding, the sum 
>>>> you would get using infinite precision to operate on the values in 
>>>> question.
>>>>
>>>> The sentence in question is intended to be a short way of saying 
>>>> "If you have same-signed infinities in your input, the result will 
>>>> be an infinity of that sign." In particular, this disallows the 
>>>> behavior that was fixed before JDK 8 GA where having infinities in 
>>>> the input would cause a NaN to be returned because of how the 
>>>> compensated summation code manipulated those values.
>>>>
>>> Thanks, I see,
>>> however it seems to me a bit confusing, since the term "infinite 
>>> exact sum" seems to me not obvious and I believe it needs some 
>>> definition. I'd like to suggest to use more straightforward 
>>> approach, that is as you've said: "If you have same-signed 
>>> infinities in your input, the result will be an infinity of that 
>>> sign.". I believe it would be more clear for end user (at least for 
>>> me :)) and from conformance point of view.
>>>
>>> Besides it seems to me a bit questionable. For instance "inexact 
>>> some" looks like more appropriate, since overflowing to infinity 
>>> occurs when _actual _sum exceeds the limit. By actual sum I mean sum 
>>> resulted from actual summation with all the rounding happened. There 
>>> wouldn't be such questions, provided straightforward approach is used.
>>>
>>> Thanks,
>>> Georgiy.
>>>
>>
>> In response to previous feedback, I propose this revised change to 
>> the specification:
>>
>> --- a/src/share/classes/java/util/DoubleSummaryStatistics.java Sat 
>> Jul 19 11:22:08 2014 +0800
>> +++ b/src/share/classes/java/util/DoubleSummaryStatistics.java Mon 
>> Jul 21 18:02:54 2014 -0700
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All 
>> rights reserved.
>> + * Copyright (c) 2012, 2014, Oracle and/or its affiliates. All 
>> rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -129,9 +129,6 @@
>>       * Returns the sum of values recorded, or zero if no values have 
>> been
>>       * recorded.
>>       *
>> -     * If any recorded value is a NaN or the sum is at any point a NaN
>> -     * then the sum will be NaN.
>> -     *
>>       * <p> The value of a floating-point sum is a function both of the
>>       * input values as well as the order of addition operations. The
>>       * order of addition operations of this method is intentionally
>> @@ -143,6 +140,44 @@
>>       * numerical sum compared to a simple summation of {@code double}
>>       * values.
>>       *
>> +     * Because of the unspecified order of operations and the
>> +     * possibility of using differing summation schemes, the output of
>> +     * this method may vary on the same input values.
>> +     *
>> +     * <p>Various conditions can result in a non-finite sum being
>> +     * computed. This can occur even if the all the recorded values
>> +     * being summed are finite. If any recorded value is non-finite,
>> +     * the sum will be non-finite:
>> +     *
>> +     * <ul>
>> +     *
>> +     * <li>If any recorded value is a NaN, then the final sum will be
>> +     * NaN.
>> +     *
>> +     * <li>If the recorded values contain one or more infinities, the
>> +     * sum will be infinite or NaN.
>> +     *
>> +     * <ul>
>> +     *
>> +     * <li>If the recorded values contain infinities of opposite sign,
>> +     * the sum will be NaN.
>> +     *
>> +     * <li>If the recorded values contain infinities of one sign and
>> +     * an intermediate sum overflows to an infinity of the opposite
>> +     * sign, the sum may be NaN.
>> +     *
>> +     * </ul>
>> +     *
>> +     * </ul>
>> +     *
>> +     * It is possible for intermediate sums of finite values to
>> +     * overflow into opposite-signed infinities; if that occurs, the
>> +     * final sum will be NaN even if the recorded values are all
>> +     * finite.
>> +     *
>> +     * If all the recorded values are zero, the sign of zero is
>> +     * <em>not</em> guaranteed to be preserved in the final sum.
>> +     *
>>       * @apiNote Values sorted by increasing absolute magnitude tend 
>> to yield
>>       * more accurate results.
>>       *
>> @@ -193,15 +228,9 @@
>>       * Returns the arithmetic mean of values recorded, or zero if no
>>       * values have been recorded.
>>       *
>> -     * If any recorded value is a NaN or the sum is at any point a NaN
>> -     * then the average will be code NaN.
>> -     *
>> -     * <p>The average returned can vary depending upon the order in
>> -     * which values are recorded.
>> -     *
>> -     * This method may be implemented using compensated summation or
>> -     * other technique to reduce the error bound in the {@link #getSum
>> -     * numerical sum} used to compute the average.
>> +     * <p> The computed average can vary numerically and have the
>> +     * special case behavior as computing the sum; see {@link #getSum}
>> +     * for details.
>>       *
>>       * @apiNote Values sorted by increasing absolute magnitude tend 
>> to yield
>>       * more accurate results.
>>
>> (With analogous changes in java/util/stream/DoubleStream.java.)
>>
>> Thanks,
>>
>> -Joe
>




More information about the core-libs-dev mailing list