Loose end: zip

[Richard Warburton]

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 <http://twitter.com/richardwarburto>