Hi Paul, On 07/16/2014 07:46 AM, Paul Sandoz wrote:
On Jul 16, 2014, at 2:29 AM, Joe Darcy <joe.da...@oracle.com> wrote: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/ Patch below.That looks a reasonable description of the constraints. Do those constraints also hold for reduce(0, Double::sum)? I think they might, but want to double check.
Yes, those constraints are also true for a simple summation.
-- In hindsight i wish that sum was specified to be equivalent to reduce(0, Double::sum). Many developers will be surprised at the performance difference (~4x) between a compensated and uncompensated sum and i do wonder how much importance they place on the former. FWIW i tried to improve the performance, but failed (should take another swing at it): https://bugs.openjdk.java.net/browse/JDK-8035561 I was contemplating making the sum() implement uncompensated and adding a new method compensatedSum(). I suspect you would prefer that to be the other way around with the even more verbose uncompensatedSum() method :-)
Your suspicion is correct :-)
My motivation for the question above is whether the specification updates will impact which way to go. Paul.
There is often a tension between safety and speed; floating-point summation is one of those cases. Simple summation is "dangerous" since it is easy to find cases where the result is arbitrarily far from the true result. If you don't care what is computed, why do you care how fast it is computed? ;-) I have more faith that Java developers who are frustrated at the slower performance of sum() will figure out how to do reduce(0, Double::sum) than I have that developers will first, be aware of a floating-point rounding problem and second, code up compensated summation to fix it.
That said, I don't oppose including a "quickSum" method to these classes. Thanks,g -Joe
