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

Georgiy Rakov georgiy.rakov at oracle.com
Tue Jul 22 15:35:03 UTC 2014

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.

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. - * *

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. + * + *

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: + * + *
    + * + *
  • If any recorded value is a NaN, then the final sum will be
    •  + * NaN. + * + *
  • If the recorded values contain one or more infinities, the
    •  + * sum will be infinite or NaN. + * + *
      + * + *
    • If the recorded values contain infinities of opposite sign,
      •  + * the sum will be NaN. + * + *
    • 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. + * + * + * + * + * + * 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 + * not 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. - * - *

      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. + *

      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