On Jul 16, 2014, at 5:39 PM, Joe Darcy <joe.da...@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.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. > > 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.
