On 01/11/2013 05:18 PM, Chris Hegarty wrote:
Now with explicit disclaimer on DoubleA*
"The order of accumulation within or across threads is not guaranteed.
Thus, this class may not be applicable if numerical stability is
required when combining values of substantially different orders of
magnitude."
It doesn't have to be substantially different order of magnitude.
For example:
double a = 1d/3d;
double b = 1d;
double x = a + a + a + b;
double y = b + a + a + a;
System.out.println(x == y);
... prints false.
Regards, Peter
Updated spec:
http://cr.openjdk.java.net/~chegar/8005311/ver.02/specdiff/java/util/concurrent/atomic/package-summary.html
Unless there are any objections, I'll finalize this spec and seek
approval for its integration.
-Chris.
On 07/01/2013 19:40, Doug Lea wrote:
On 01/07/13 14:07, Joe Darcy wrote:
Hello,
I had a question about how the double accumulation logic was intended
to be
used. I've taken a quick look at the code and it uses straightforward
"sum =
sum + nextValue" code to compute the double sum. Summing doubles
values with
code numerical accuracy is surprisingly tricky and if the
DoubleAccumulator code
is meant for wide use, I'd recommend using instead some form of
compensated
summation:
http://en.wikipedia.org/wiki/Kahan_summation_algorithm
I'm sympathetic...
Complete lack of control over arithmetic issues (here and for
plain atomics) led me to resist offering Double versions for
years. But many people are content with the scalability vs
numerical stability tradeoffs intrinsic here (and I think
unsolvable). I suppose it could stand an explicit disclaimer
rather than the implicit one there now.
How about: "The order of accumulation of sums across threads is
uncontrolled. Numerical stability of results is not guaranteed
when values of substantially different orders of magnitude are
combined"
Or something better?
-Doug
