JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs
paul.sandoz at oracle.com
Wed Jul 16 14:46:23 UTC 2014
On Jul 16, 2014, at 2:29 AM, Joe Darcy <joe.darcy at oracle.com> wrote:
> Please review my changes to address:
> JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs
> 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):
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.
More information about the core-libs-dev