Loose end: zip

[Paul Sandoz]

Hi Richard,

Thanks for the feedback. I presume if developers are capable of understanding those topics you mention they are capable of, and as you say, most likely will implement their own zip-like abstractions, perhaps with better parallel characteristics.

This seems like a no-win situation here.

If we keep zip there will be demands for primitive support, "I want java.lang.Pair!", and "i want to keep on trucking processing addition elements of the longer stream with some identity or default value" i.e. zip satisfies the "tick test" but perhaps not much else.

My inclination would be to field questions of why there is no zip (leading to wider the tuples discussion) and provide an example of zip (much like the current implementation).

Paul.

On Jun 11, 2013, at 3:59 PM, Richard Warburton <richard.warburton at gmail.com> wrote:

> Hi,
> 
> If anyone has experimented with Streams.zip can you provide some feedback? see email below for context.
> 
> Thanks for asking ;)
> 
> > Still feeling kind of YAGNI on zip, for the reasons cited in the message below, plus:
> > - No primitive versions (would require new SAMs)
> > - Hard to parallelize
> > - Multiple ways to deal with streams of different length; we pick one
> >
> > Might this be something best provided by some other library than the JDK?  Or as a code example somewhere people can crib from to roll their own?
> >
> > On 5/1/2013 5:10 PM, Brian Goetz wrote:
> >> Right, but the question is, how badly can we implement it and have it
> >> not be worse than nothing?  And, with the current performance
> >> characteristics (new object per element), are we below that threshold?
> >>
> >> My problem is the same as with flatMap -- these are idioms from other
> >> languages that *translate poorly* to Java because of the lack of tuples
> >> and other structural types.  (The flatMap we got left with -- which I
> >> reluctantly supported as the lesser of evils -- is, coincidentally, the
> >> only other stream operation that has allocation-per-element.)  At what
> >> level of translation-fidelity loss do we say "yeah, it works great in
> >> that other environment, but too much is lost in translation"?
> >>
> >> I don't doubt the utility of zip, or the fact that Joe-alikes will want
> >> it, and would be bummed to not find it.  My question is whether the
> >> crappy zip we can have is better than no zip.  (Where better doesn't
> >> just mean "better than nothing", but carries its weight.)
> 
> The things that I've come across where Streams.zip is appropriate are all fairly mathematical in nature:
> 
>  - vector dot product
>  - signal convolution
>  - cross-correlation + auto-correlation
>  - finite impulse response filters
>  - discrete-time fourier transform
> 
> The last 4 examples are all situations in which people do generally care about the implementation's performance, rather than being willing to pay a cost in favour of abstraction.  They are also situations in which you want primitives, rather than boxed numerical values.  Furthermore convolution, cross-correlation of them are implementable in terms of the fourier transform and auto-correlation in terms of cross-correlation.  So I guess my usage of Streams.zip suggests that a slow, boxed only, version wouldn't actually be used to implement the algorithms that its useful for.
> 
> There's certainly user demand for it though.  Before zip was added we did have several people ask about zip at lambdas hackdays.  Sadly I failed to ask them why and what their motivation was.  Sorry about that.  Its almost inevitable that if you leave it out that people will be asking the question "why is there no zip or zipWith in Java?" until the end of time in the same way that people ask about tuples until the end of time.
> 
> regards,
> 
>   Dr. Richard Warburton
> 
>   http://insightfullogic.com
>   @RichardWarburto