[concurrency-interest] Ops type names

Doug Lea dl at cs.oswego.edu
Tue Jan 8 07:22:37 EST 2008

Doug Lea wrote:
> Notice also that Ops does not even try to define the various
> scalar specializations of Combiners. Which here might look like,
> for example:
>    DoubleXLongToDouble
> (Luckily none of the ParallelArray classes use such types.)

I should have noted that this is also subject to change.
Currently, operations on Combiners are not integrated as nicely
as those using filters and mappings. You'd like to be able to
write, for example:
   a.withCombination(b, multiplier).max()
rather than
   a.combine(b, multiplier).max();
to find the maximum value of products of elements in a and b.
This would be in keeping with the idea that ParallelArray allows
you to build up expressions that can be performed in a single
parallel step. This saves time by eliminating the need for
multiple parallel passes, and saves space by avoiding storage
of intermediate arrays. (Plus, down the road, one can imagine
people coming up with expression optimizers that take various
With* elements and produce evaluation orders likely to be fastest.
This is similar to database query optimization.)

The main reason this isn't supported (yet?) is that it creates
another combinatorial API and implementation blowup if done
completely orthogonally, As in:
(which would entail creating internal classes such as
WithBoundedFilteredMappedCombination to maintain all the bookkeeping
needed to flatten out the leaf computations, which is needed to
get good parallel performance.)

Plus it needs type names AXBToC for A, B, C in {Object, long, double}.
Plus a zillion compoundCombiner methods to allow cascading.

Given all the obstacles in supporting a fully integrated version,
I'm still considering alternative ways of providing this kind of
functionality. Suggestions welcome.
Until then, people can always use multi-step expressions.


More information about the Concurrency-interest mailing list