Re: Fwd: JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs
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
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
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
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
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
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
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
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
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
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
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
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
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
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