Hi --

On Fri, 15 Nov 2002, Tim Sutherland wrote:

> In article <20021112020739J.maki / rubycolor.org>, TAKAHASHI Masayoshi wrote:
> [...]
> >  There is a discussion whether Enumerable#zip is appropriate or not.
> >
> >   ex.
> >    * Enumerable.zip(a, b, c...)
> >    * Array.zip(a, b, c...)
> >    * [a, b, c..].zip
>
> How about the latter, with an optional block.
>
> a = [1, 0, 3]
> b = [2, 1, 2]
> c = [3, 2, 1]
>
> [a, b, c].zip { |x, y, z| x*y + z } #=> [5, 2, 7]
>
> Now zip is like lisp's map.

The optional block is cool, but I don't know about having the return
value of the method being different depending on the presence or
absence of a block.  I'm not sure, though.

Many moons ago I wrote Array#braid, which was essentially a
n-dimensional 'zip'.  It returned a "braided" version of the input
arrays:

  a.braid(b,c) # => [ [1,2,3], [0,1,2], [3,2,1] ]

and it could take a block:

  res = []
  a.braid(b,c) { |x,y,z| res << x*y+z }

but the actual return value of the method stayed the same.  (Not that
my #braid method is a model of Ruby perfection -- the extant version
seems to have a rogue concat where a << should be.... :-)  So it was
more like #each than #map, or something.  I don't know whether there's
a real underlying reason to do it this way.


David

-- 
David Alan Black
home: dblack / candle.superlink.net
work: blackdav / shu.edu
Web:  http://pirate.shu.edu/~blackdav