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

[Paul Sandoz]

On Jul 16, 2014, at 5:39 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
> 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.
> 

Ok. +1 from me for the review.


> 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? ;-)

Certainly if sum() always returned 0.0 that would be a problem. I think in reality it is more nuanced regarding the interval of which the actual sum would be within. (As an aside i wish we had support interval arithmetic.)


> 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's a fair point, but i don't have a sense of how problematic an uncompensated sum is for developers. 

Perhaps we can add an apiNote to the sum method mentioning performance?


> That said, I don't oppose including a "quickSum" method to these classes.
> 

OK, or even "basicSum".

Pail.