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

[Joe Darcy]

Hi Paul,

On 07/16/2014 07:46 AM, Paul Sandoz wrote:
> On Jul 16, 2014, at 2:29 AM, Joe Darcy <joe.darcy at 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