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

2014-07-25 Thread Georgiy Rakov


On 22.07.2014 20:12, Joe Darcy wrote:

Hello Georgiy,

On 07/22/2014 08:49 AM, Georgiy Rakov wrote:

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.



I would argue the statement above is just a clarification of the 
existing (non) specification of how the method can operate.


Ideally, the sum method would state an error bound for its operation. 
There are bugs in this subcomponent mentioning adding such a bound, 
which may be done later in JDK 9.


-Joe
The sentence above and the following one actually say about 
implementation details which couldn't be verified by conformance tests - 
what is the order of summation, what is the summation scheme, whether 
the result varies because of different summation scheme.


 * 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
 * not defined to allow for implementation flexibility to improve
 * the speed and accuracy of the computed result.

What do you think about turning them into implementation notes? They 
won't be normative in this case.


But I'd like to say that following sentence I would leave as normative 
since it talks about the condition which could be used in conformance 
tests - to reduce the error bound in the numerical sum compared to a 
simple summation of {@code double} values.


 * In particular, this method may be implemented using compensated
 * summation or other technique to reduce the error bound in the
 * numerical sum compared to a simple summation of {@code double}
 * values.

Thanks,
Georgiy.


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

2014-07-25 Thread Joe Darcy

Hello Georgiy,

On 7/25/2014 5:44 AM, Georgiy Rakov wrote:


On 22.07.2014 20:12, Joe Darcy wrote:

Hello Georgiy,

On 07/22/2014 08:49 AM, Georgiy Rakov wrote:

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.



I would argue the statement above is just a clarification of the 
existing (non) specification of how the method can operate.


Ideally, the sum method would state an error bound for its operation. 
There are bugs in this subcomponent mentioning adding such a bound, 
which may be done later in JDK 9.


-Joe
The sentence above and the following one actually say about 
implementation details which couldn't be verified by conformance tests 
- what is the order of summation, what is the summation scheme, 
whether the result varies because of different summation scheme.


 * 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
 * not defined to allow for implementation flexibility to improve
 * the speed and accuracy of the computed result.

What do you think about turning them into implementation notes? They 
won't be normative in this case.


But I'd like to say that following sentence I would leave as normative 
since it talks about the condition which could be used in conformance 
tests - to reduce the error bound in the numerical sum compared to a 
simple summation of {@code double} values.


 * In particular, this method may be implemented using compensated
 * summation or other technique to reduce the error bound in the
 * numerical sum compared to a simple summation of {@code double}
 * values.



The writers of conformance tests are not the sole consumers of the 
javadoc of Java SE nor are they even the primary consumers. Therefore, I 
do not think the text of the javadoc should be contorted so that all 
sentences that cannot be viewed as containing a testable assertion are 
banished to an @implnote.


The main text of the javadoc contains both normative and informative 
sentences. I don't plan further edits to the text in question for this bug.


Regards,

-Joe


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

2014-07-22 Thread Georgiy Rakov

Hello Joe,

if I understand correctly the doc doesn't specify exact circumstances 
leading to infinities, it just has general assertion:


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

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

2014-07-22 Thread Georgiy Rakov

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.
+ *
+ * pVarious 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
+ *
+ * liIf any recorded value is a NaN, then the final sum will be
+ * NaN.
+ *
+ * liIf the recorded values contain one or more infinities, the
+ * sum will be infinite or NaN.
+ *
+ * ul
+ *
+ * liIf the recorded values contain infinities of opposite sign,
+ * the sum will be NaN.
+ *
+ * liIf 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
+ * emnot/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 

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

2014-07-22 Thread Joe Darcy

Hello Georgiy,

On 07/22/2014 08:49 AM, Georgiy Rakov wrote:

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.



I would argue the statement above is just a clarification of the 
existing (non) specification of how the method can operate.


Ideally, the sum method would state an error bound for its operation. 
There are bugs in this subcomponent mentioning adding such a bound, 
which may be done later in JDK 9.


-Joe


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

2014-07-22 Thread Georgiy Rakov


On 22.07.2014 20:12, Joe Darcy wrote:

Hello Georgiy,

On 07/22/2014 08:49 AM, Georgiy Rakov wrote:

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.



I would argue the statement above is just a clarification of the 
existing (non) specification of how the method can operate.


Ideally, the sum method would state an error bound for its operation. 
There are bugs in this subcomponent mentioning adding such a bound, 
which may be done later in JDK 9.


Do I understand correctly that your opinion is that for the present 
moment this method is actually untestable from conformance point of view?


- Georgiy.

-Joe




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

2014-07-22 Thread Joe Darcy

On 07/22/2014 09:23 AM, Georgiy Rakov wrote:


On 22.07.2014 20:12, Joe Darcy wrote:

Hello Georgiy,

On 07/22/2014 08:49 AM, Georgiy Rakov wrote:

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.



I would argue the statement above is just a clarification of the 
existing (non) specification of how the method can operate.


Ideally, the sum method would state an error bound for its operation. 
There are bugs in this subcomponent mentioning adding such a bound, 
which may be done later in JDK 9.


Do I understand correctly that your opinion is that for the present 
moment this method is actually untestable from conformance point of view?





Whatever the testability status of the method is as of Java SE 8, I 
believe is unchanged by the addition of the sentence in question.


Cheers,

-Joe



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

2014-07-22 Thread Joe Darcy

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:


 * liIf 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
 *
 * liIf the recorded values contain infinities of opposite sign,
 * the sum will be NaN.
 *
 * liIf 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.
+ *
+ * pVarious 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 

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

2014-07-21 Thread Joe Darcy

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.
+ *
+ * pVarious 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
+ *
+ * liIf any recorded value is a NaN, then the final sum will be
+ * NaN.
+ *
+ * liIf the recorded values contain one or more infinities, the
+ * sum will be infinite or NaN.
+ *
+ * ul
+ *
+ * liIf the recorded values contain infinities of opposite sign,
+ * the sum will be NaN.
+ *
+ * liIf 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
+ * emnot/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.
- *
- * pThe 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 

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

2014-07-18 Thread Georgiy Rakov

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

Thank you,
Georgiy.

On 16.07.2014 16:37, Paul Sandoz wrote:



Begin forwarded message:


*From: *Joe Darcy joe.da...@oracle.com mailto:joe.da...@oracle.com
*Subject: **JDK 9 RFR of JDK-8030942: Explicitly state floating-point 
summation requirements on non-finite inputs*

*Date: *July 16, 2014 2:29:46 AM GMT+02:00
*To: *Core-Libs-Dev core-libs-dev@openjdk.java.net 
mailto:core-libs-dev@openjdk.java.net


Hello,

Please review my changes to address:

   JDK-8030942: Explicitly state floating-point summation 
requirements on non-finite inputs
http://cr.openjdk.java.net/~darcy/8030942.0/ 
http://cr.openjdk.java.net/%7Edarcy/8030942.0/


Patch below.

Thanks,

-Joe

--- old/src/share/classes/java/util/DoubleSummaryStatistics.java 
2014-07-15 17:26:41.0 -0700
+++ new/src/share/classes/java/util/DoubleSummaryStatistics.java 
2014-07-15 17:26:41.0 -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,23 @@
 * numerical sum compared to a simple summation of {@code double}
 * values.
 *
+ * pIf any recorded value is a NaN or the intermediate sum is at
+ * any point a NaN, then the final sum will be NaN.
+ *
+ * If the recorded values contain infinities of opposite sign, the
+ * final sum will 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 the exact sum is infinite, a properly-signed infinity is
+ * returned.
+ *
+ * If all the recorded values are zero, the sign of zero is
+ * emnot/em guaranteed to be preserved in the final sum.
+ *
 * @apiNote Values sorted by increasing absolute magnitude tend 
to yield

 * more accurate results.
 *
@@ -193,9 +207,6 @@
 * 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.
- *
 * pThe average returned can vary depending upon the order in
 * which values are recorded.
 *
@@ -203,6 +214,10 @@
 * other technique to reduce the error bound in the {@link #getSum
 * numerical sum} used to compute the average.
 *
+ * pThis method can return a NaN or infinite result in the same
+ * kind of numerical situations as {@linkplain #getSum() the sum}
+ * can be NaN or infinite, respectively.
+ *
 * @apiNote Values sorted by increasing absolute magnitude tend 
to yield

 * more accurate results.
 *
--- old/src/share/classes/java/util/stream/DoubleStream.java 
2014-07-15 17:26:42.0 -0700
+++ new/src/share/classes/java/util/stream/DoubleStream.java 
2014-07-15 17:26:42.0 -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
@@ -470,10 +470,7 @@
 * code is not necessarily equivalent to the summation computation
 * done by this method.
 *
- * pIf any stream element 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
+ * pThe 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 not defined to allow for implementation
@@ -485,6 +482,23 @@
 * numerical sum compared to a simple summation of {@code double}
 * values.
 *
+ * pIf any stream element is a NaN or the intermediate sum is at
+ * any point a NaN, then the final sum will be NaN.
+ *
+ * If the stream elements 

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

2014-07-18 Thread Joe Darcy

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.


HTH,

-Joe



Thank you,
Georgiy.

On 16.07.2014 16:37, Paul Sandoz wrote:



Begin forwarded message:


*From: *Joe Darcy joe.da...@oracle.com mailto:joe.da...@oracle.com
*Subject: **JDK 9 RFR of JDK-8030942: Explicitly state 
floating-point summation requirements on non-finite inputs*

*Date: *July 16, 2014 2:29:46 AM GMT+02:00
*To: *Core-Libs-Dev core-libs-dev@openjdk.java.net 
mailto:core-libs-dev@openjdk.java.net


Hello,

Please review my changes to address:

   JDK-8030942: Explicitly state floating-point summation 
requirements on non-finite inputs
http://cr.openjdk.java.net/~darcy/8030942.0/ 
http://cr.openjdk.java.net/%7Edarcy/8030942.0/


Patch below.

Thanks,

-Joe

--- old/src/share/classes/java/util/DoubleSummaryStatistics.java 
2014-07-15 17:26:41.0 -0700
+++ new/src/share/classes/java/util/DoubleSummaryStatistics.java 
2014-07-15 17:26:41.0 -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,23 @@
 * numerical sum compared to a simple summation of {@code double}
 * values.
 *
+ * pIf any recorded value is a NaN or the intermediate sum is at
+ * any point a NaN, then the final sum will be NaN.
+ *
+ * If the recorded values contain infinities of opposite sign, the
+ * final sum will 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 the exact sum is infinite, a properly-signed infinity is
+ * returned.
+ *
+ * If all the recorded values are zero, the sign of zero is
+ * emnot/em guaranteed to be preserved in the final sum.
+ *
 * @apiNote Values sorted by increasing absolute magnitude tend 
to yield

 * more accurate results.
 *
@@ -193,9 +207,6 @@
 * 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.
- *
 * pThe average returned can vary depending upon the order in
 * which values are recorded.
 *
@@ -203,6 +214,10 @@
 * other technique to reduce the error bound in the {@link #getSum
 * numerical sum} used to compute the average.
 *
+ * pThis method can return a NaN or infinite result in the same
+ * kind of numerical situations as {@linkplain #getSum() the sum}
+ * can be NaN or infinite, respectively.
+ *
 * @apiNote Values sorted by increasing absolute magnitude tend 
to yield

 * more accurate results.
 *
--- old/src/share/classes/java/util/stream/DoubleStream.java 
2014-07-15 17:26:42.0 -0700
+++ new/src/share/classes/java/util/stream/DoubleStream.java 
2014-07-15 17:26:42.0 -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
@@ -470,10 +470,7 @@
 * code is not necessarily equivalent to the summation computation
 * done by this method.
 *
- * pIf any stream element is a NaN or the sum is at any point 
a NaN

- * then the sum will be 

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

2014-07-18 Thread Georgiy Rakov


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.


HTH,

-Joe



Thank you,
Georgiy.

On 16.07.2014 16:37, Paul Sandoz wrote:



Begin forwarded message:


*From: *Joe Darcy joe.da...@oracle.com mailto:joe.da...@oracle.com
*Subject: **JDK 9 RFR of JDK-8030942: Explicitly state 
floating-point summation requirements on non-finite inputs*

*Date: *July 16, 2014 2:29:46 AM GMT+02:00
*To: *Core-Libs-Dev core-libs-dev@openjdk.java.net 
mailto:core-libs-dev@openjdk.java.net


Hello,

Please review my changes to address:

   JDK-8030942: Explicitly state floating-point summation 
requirements on non-finite inputs
http://cr.openjdk.java.net/~darcy/8030942.0/ 
http://cr.openjdk.java.net/%7Edarcy/8030942.0/


Patch below.

Thanks,

-Joe

--- old/src/share/classes/java/util/DoubleSummaryStatistics.java 
2014-07-15 17:26:41.0 -0700
+++ new/src/share/classes/java/util/DoubleSummaryStatistics.java 
2014-07-15 17:26:41.0 -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,23 @@
 * numerical sum compared to a simple summation of {@code double}
 * values.
 *
+ * pIf any recorded value is a NaN or the intermediate sum is at
+ * any point a NaN, then the final sum will be NaN.
+ *
+ * If the recorded values contain infinities of opposite sign, the
+ * final sum will 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 the exact sum is infinite, a properly-signed infinity is
+ * returned.
+ *
+ * If all the recorded values are zero, the sign of zero is
+ * emnot/em guaranteed to be preserved in the final sum.
+ *
 * @apiNote Values sorted by increasing absolute magnitude tend 
to yield

 * more accurate results.
 *
@@ -193,9 +207,6 @@
 * 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.
- *
 * pThe average returned can vary depending upon the order in
 * which values are recorded.
 *
@@ -203,6 +214,10 @@
 * other technique to reduce the error bound in the {@link #getSum
 * numerical sum} used to compute the average.
 *
+ * pThis method can return a NaN or infinite result in the same
+ * kind of numerical situations as {@linkplain #getSum() the sum}
+ * can be NaN or infinite, respectively.
+ *
 * @apiNote Values 

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

2014-07-17 Thread Georgiy Rakov

Hello,

let's consider following excerpt:

 149  * It is possible for intermediate sums of finite values to
 150  * overflow into opposite-signed infinities; if that occurs, the
 151  * final sum will be NaN even if the recorded values are all
 152  * finite.

It says about intermediate sums. I could suppose it implies those 
intermediate sums which are produced during parallel processing. If my 
supposition is true then:


1) I think it would be good to mention it explicitly because otherwise 
this excerpt could also be interpreted as if it talks about intermediate 
sums produced somehow during sequential processing, I'm not sure if this 
is desirable interpretation.
2) For DoubleSummaryStatistics those intermediate sums are added by 
calling combine I suppose, so I think it would be good to specify in 
DoubleSummaryStatistics doc, that turning two opposite-signedinfinities 
into NaN is actually resulted from calling combine().
3) The result produced from sequential and parallel processing could 
differ, say considerably. That is for sequential processing it could be 
+/-INFINITE while for parallel processing - NaN. Would it be good to 
mention it?


Thank you,
Georgiy.

On 16.07.2014 16:37, Paul Sandoz wrote:



Begin forwarded message:


*From: *Joe Darcy joe.da...@oracle.com mailto:joe.da...@oracle.com
*Subject: **JDK 9 RFR of JDK-8030942: Explicitly state floating-point 
summation requirements on non-finite inputs*

*Date: *July 16, 2014 2:29:46 AM GMT+02:00
*To: *Core-Libs-Dev core-libs-dev@openjdk.java.net 
mailto:core-libs-dev@openjdk.java.net


Hello,

Please review my changes to address:

   JDK-8030942: Explicitly state floating-point summation 
requirements on non-finite inputs
http://cr.openjdk.java.net/~darcy/8030942.0/ 
http://cr.openjdk.java.net/%7Edarcy/8030942.0/


Patch below.

Thanks,

-Joe

--- old/src/share/classes/java/util/DoubleSummaryStatistics.java 
2014-07-15 17:26:41.0 -0700
+++ new/src/share/classes/java/util/DoubleSummaryStatistics.java 
2014-07-15 17:26:41.0 -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,23 @@
 * numerical sum compared to a simple summation of {@code double}
 * values.
 *
+ * pIf any recorded value is a NaN or the intermediate sum is at
+ * any point a NaN, then the final sum will be NaN.
+ *
+ * If the recorded values contain infinities of opposite sign, the
+ * final sum will 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 the exact sum is infinite, a properly-signed infinity is
+ * returned.
+ *
+ * If all the recorded values are zero, the sign of zero is
+ * emnot/em guaranteed to be preserved in the final sum.
+ *
 * @apiNote Values sorted by increasing absolute magnitude tend 
to yield

 * more accurate results.
 *
@@ -193,9 +207,6 @@
 * 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.
- *
 * pThe average returned can vary depending upon the order in
 * which values are recorded.
 *
@@ -203,6 +214,10 @@
 * other technique to reduce the error bound in the {@link #getSum
 * numerical sum} used to compute the average.
 *
+ * pThis method can return a NaN or infinite result in the same
+ * kind of numerical situations as {@linkplain #getSum() the sum}
+ * can be NaN or infinite, respectively.
+ *
 * @apiNote Values sorted by increasing absolute magnitude tend 
to yield

 * more accurate results.
 *
--- old/src/share/classes/java/util/stream/DoubleStream.java 
2014-07-15 17:26:42.0 -0700
+++ new/src/share/classes/java/util/stream/DoubleStream.java 
2014-07-15 17:26:42.0 -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 

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

2014-07-17 Thread Joe Darcy

Hello,

On 07/17/2014 04:33 AM, Georgiy Rakov wrote:

Hello,

let's consider following excerpt:

  149  * It is possible for intermediate sums of finite values to
  150  * overflow into opposite-signed infinities; if that occurs, the
  151  * final sum will be NaN even if the recorded values are all
  152  * finite.
It says about intermediate sums. I could suppose it implies those 
intermediate sums which are produced during parallel processing. If my 
supposition is true then:


Parallel processing is one possible way two intermediate sums can be 
combined, but since the order of summation is intentionally undefined, 
even a serial-only computation can have two intermediate sums being 
combined (as opposed to only combining a new element to an intermediate 
sum).


For example, an allowable implementation of sum() would do pairwise 
combination of successive elements, then add up pairs of pairs, etc., 
until the final sum is reached.




1) I think it would be good to mention it explicitly because otherwise 
this excerpt could also be interpreted as if it talks about 
intermediate sums produced somehow during sequential processing, I'm 
not sure if this is desirable interpretation.
2) For DoubleSummaryStatistics those intermediate sums are added by 
calling combine I suppose, so I think it would be good to specify in 
DoubleSummaryStatistics doc, that turning two 
opposite-signedinfinities into NaN is actually resulted from calling 
combine().


I don't think such detail is necessary or helpful.

You can get opposite signed infinities as values in the input. Or you 
can get opposite signed infinities from being given one infinity as a 
starting value and then getting the other infinity from overflow. Or you 
can get both infinities from overflow.


I don't think drawing too much distinction between these cases is needed.


3) The result produced from sequential and parallel processing could 
differ, say considerably. That is for sequential processing it could 
be +/-INFINITE while for parallel processing - NaN. Would it be good 
to mention it?


The methods already state something like:

 132  * p The value of a floating-point sum is a function both of the
 133  * input values as well as the order of addition operations. The
 134  * order of addition operations of this method is intentionally
 135  * not defined to allow for implementation flexibility to improve
 136  * the speed and accuracy of the computed result.

Parallel vs serial is only one possible source of the differences that 
the specification allows; I don't think it is worthwhile calling it out 
specially.


-Joe



Thank you,
Georgiy.

On 16.07.2014 16:37, Paul Sandoz wrote:



Begin forwarded message:


*From: *Joe Darcy joe.da...@oracle.com mailto:joe.da...@oracle.com
*Subject: **JDK 9 RFR of JDK-8030942: Explicitly state 
floating-point summation requirements on non-finite inputs*

*Date: *July 16, 2014 2:29:46 AM GMT+02:00
*To: *Core-Libs-Dev core-libs-dev@openjdk.java.net 
mailto:core-libs-dev@openjdk.java.net


Hello,

Please review my changes to address:

   JDK-8030942: Explicitly state floating-point summation 
requirements on non-finite inputs
http://cr.openjdk.java.net/~darcy/8030942.0/ 
http://cr.openjdk.java.net/%7Edarcy/8030942.0/


Patch below.

Thanks,

-Joe

--- old/src/share/classes/java/util/DoubleSummaryStatistics.java 
2014-07-15 17:26:41.0 -0700
+++ new/src/share/classes/java/util/DoubleSummaryStatistics.java 
2014-07-15 17:26:41.0 -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,23 @@
 * numerical sum compared to a simple summation of {@code double}
 * values.
 *
+ * pIf any recorded value is a NaN or the intermediate sum is at
+ * any point a NaN, then the final sum will be NaN.
+ *
+ * If the recorded values contain infinities of opposite sign, the
+ * final sum will 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 the exact sum is infinite, a properly-signed infinity is
+ * returned.
+ *
+ * If