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