Dot Product Thoughts

[Brian Goetz]

> 1. There's a Double::sum, but no Double::multiply, etc.  I appreciate you
> have to stop somewhere, but is sum the place to stop?  Might be worth
> adding other basic arithmetic operations.

Yes, we definitely stopped in the wrong place :)

Sensible would be the ability to express all built-in operators as 
functions so they can be used as reducers.

I suspect that the naming convention we've started down the road of 
(sum) may not scale as well as we'd like.  Peraps that should be 
reconsidered now as we now have methods like IntStream.sum() and no 
longer have as much need for Integer::sum when used as a reducer; 
perhaps it should be renamed opPlus or opSum or some such.

> 2. There appears to be a zip function now, but with no overloads for
> primitive streams.  I managed to guess at Streams.zip as the location, so
> one data point, but good news on that front.

Yeah, this one is on the fence.  We should go one way or the other.

> 3. If I have an double[] is there is a cleaner way of making a DoubleStream
> than adding every element to the builder?

Arrays.stream(double[])

or, alternately, if we didn't have that,

  Streams.intRange(0, array.length).map(i -> array[i])

> 4. A performance comparison with a trivial imperative example resulted in a
> ~16x slowdown moving to lambdas.  I'm willing to take some performance hit
> for the nicer code, but 16x is a lot higher than I would have expected or
> hoped for.  I'll try to have a look at some more 'real world' examples in
> future, but even then being this much slower on mathematical problems will
> cause some people trouble.

The real cost is in replacing the primitive operators with method 
invocations; the cost of the streams framework is a smaller component. 
Now, where'd I put that jar of Inline Sauce...

> Notes:
>   * When I profiled the hotspot wasn't in boxing/unboxing but
> Iterator.forEachRemaining - pretty hot as well, ~ 95% of execution
> time.  I suspect the conclusion is that the computational work of
> actually performing arithmetic is entirely dominated by the cost of
> iteration in the framework.

Not iteration, invocation.