Hello Joe,
following assertion seems to me too loose:
* 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.
as I see it this assertion imposes no constraints on how the sum can be
varied. Strictly speaking, I'm afraid from conformance point of view it
can cause the entire method to become untestable.
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
