RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder
peter.levart at gmail.com
Fri Jan 11 16:35:30 UTC 2013
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
It doesn't have to be substantially different order of magnitude.
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.
> Updated spec:
> Unless there are any objections, I'll finalize this spec and seek
> approval for its integration.
> On 07/01/2013 19:40, Doug Lea wrote:
>> On 01/07/13 14:07, Joe Darcy wrote:
>>> 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
>> 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
>> Or something better?
More information about the core-libs-dev