RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder

[Chris Hegarty]

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."

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
>