Numeric (and accumulators)

[Doug Lea]

On 09/17/12 11:40, Brian Goetz wrote:
>> One reason for integrating into j.u.c is that keyed versions of
>> these forms would need to generalize what is now LongAdderTable
>
> How much better (pick your metrics) is the keyed form of LAT than a CHM of
> Accumulators?

No better at all performance-wise. LAT exists/existed because
the implementations of update/get using CHM+LongAdder were
initially too messy and non-obvious.
But by adding various CHM methods over the past year,
they are getting close enough to "easy" that LAT could go away
as a class and turn into a javadoc (and/or tutorial) example.
I think that planning for it to go away is a good stance --
maybe something making it and similar constructions a bit
simpler yet will occur to us.

BTW, at some point we should discuss whether/how to support
the various CHM additions in other Map classes.

>
>> /**
>>   * Example: Maps from keys to Accumulators can be used to create
>> Histograms
>>   * (frequency maps) and related tables.
>>   *
>>   * To increment a count, installing if not already present:
>>   *  map.computeIfAbsent(key, () ->
>> LongAccumulator.optimisticSum()).update(1L);

(Actually, "k ->", not "() ->")

>>   *
>>   * To determine the sum for a key, it is convenient to create a
>>   * singleton static EMPTY_ACCUMULATOR, enabling
>>   *   long sum = map.getValueOrDefault(key, EMPTY_ACCUMULATOR).get();
>>   */
>>
>> Any thoughts on this?
>
> Like it.  Does that mean we don't need LAT at all?
>