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. -- 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 :-) My motivation for the question above is whether the specification updates will impact which way to go. Paul.
