Numeric (and accumulators)

[Brian Goetz]

>> These guys also need companion classes that are mutable,
>
> Like for example Atomic{Integer,Long}? :-)

So, writing out the complete set of candidate numeric types that have 
been proposed (we can prune them later):

  - New interface BoxedPrimitive extends Number (Joe)
  - New interface Numeric<BoxedPrimitive> (Doug)
  - Mutable implementation classes of Numeric (Brian)
  - Complete the set of atomic implementation classes (Doug)
  - Accumulator classes (Doug)

I'll just say that we don't need to get caught up in premature 
either/or; if all of these are worth having, we can have them.

> public abstract class LongAccumulator implements Numeric<Long> {

I like these.  I believe that they all assume commutative combination 
functions, not simply associative (what are sometimes called abelian 
monoids, rather than ordinary monoids)?

> In some testing I've done using them; as in:
>    for each element x in parallel { adder.update(x); }
> is only around 25% slower than clever reduction schemes even
> on machines with lots of cores and updates. This is worth
> avoiding when possible, but the option is worth providing
> for the cases where people don't know of an appropriate reduction.

Can you clarify what you mean by "clever reduction scheme"?

> All of these might live in package java.util.functions?

Trying to avoid putting (nontrivial) implementations in j.u.f.