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