JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs
joe.darcy at oracle.com
Wed Jul 16 15:39:34 UTC 2014
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:
>> 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.
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):
> 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.
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.
More information about the core-libs-dev