RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder
Peter Levart
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
> 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
>>
More information about the core-libs-dev
mailing list