[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: How to operate on 2 arrays simultaneously?

Dan Diebolt

9/10/2008 3:59:00 PM

>There has got to be a more elegant solution than this.

I use .each_with_index to walk parallel arrays:

a=[1,2,3]
b=%w(x y z)
a.each_with_index do |item,index|
puts "item=#{item} index=#{index} a[#{index}]=#{a[index]} b[#{index}]=#{b[index]}"
end

9 Answers

Jamey Cribbs

9/10/2008 4:21:00 PM

0

Take a look at the zip method.

Jamey


On Wed, Sep 10, 2008 at 11:59 AM, DanDiebolt.exe <dandiebolt@yahoo.com> wrote:
>>There has got to be a more elegant solution than this.
>
> I use .each_with_index to walk parallel arrays:
>
> a=[1,2,3]
> b=%w(x y z)
> a.each_with_index do |item,index|
> puts "item=#{item} index=#{index} a[#{index}]=#{a[index]} b[#{index}]=#{b[index]}"
> end
>
>
>

matt

9/10/2008 4:31:00 PM

0

DanDiebolt.exe <dandiebolt@yahoo.com> wrote:

> >There has got to be a more elegant solution than this.
>
> I use .each_with_index to walk parallel arrays:

So did I until the other answers in this thread taught me about zip! :)
m.

--
matt neuburg, phd = matt@tidbits.com, http://www.tidbits...
Leopard - http://www.takecontrolbooks.com/leopard-custom...
AppleScript - http://www.amazon.com/gp/product/...
Read TidBITS! It's free and smart. http://www.t...

ara.t.howard

9/10/2008 4:36:00 PM

0


On Sep 10, 2008, at 10:28 AM, matt neuburg wrote:

> So did I until the other answers in this thread taught me about
> zip! :)


be careful with zip

a = big
b = big

huge_new_array = a.zip(b)

another_huge_new_array = huge_new_array.each{|a,b| a + b}


using something like each_with_index constructs no new array

a @ http://codeforp...
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama




Martin DeMello

9/10/2008 5:10:00 PM

0

On Wed, Sep 10, 2008 at 9:35 AM, ara.t.howard <ara.t.howard@gmail.com> wrote:
>
> be careful with zip
>
> a = big
> b = big
>
> huge_new_array = a.zip(b)
>
> another_huge_new_array = huge_new_array.each{|a,b| a + b}

zip takes a block, even in 1.8, though sadly it yields without
accumulating so you have to do it yourself. but this works:

c = []; a.zip(b) {|i, j| c << f(i,j)}

martin

matt

9/10/2008 7:06:00 PM

0

ara.t.howard <ara.t.howard@gmail.com> wrote:

> be careful with zip
>
> a = big
> b = big
>
> huge_new_array = a.zip(b)

Everything in Ruby is a pointer. If a[0] is a pointer to a "big long
string", then a.zip(b)[0][0] is a pointer to the very same "big long
string" - not a copy of the string. So creating the "huge_new_array"
just creates some new pointers, right? And pointers are very small. So
for huge_new_array to be a problem, the existence of a and b would have
to have been problematic to start with - meaning that they would have to
have huge length. The amount of *data* in the story (stuff like "big
long string") is not increased.

m.
--
matt neuburg, phd = matt@tidbits.com, http://www.tidbits...
Leopard - http://www.takecontrolbooks.com/leopard-custom...
AppleScript - http://www.amazon.com/gp/product/...
Read TidBITS! It's free and smart. http://www.t...

ara.t.howard

9/10/2008 7:24:00 PM

0


On Sep 10, 2008, at 1:03 PM, matt neuburg wrote:

> Everything in Ruby is a pointer. If a[0] is a pointer to a "big long
> string", then a.zip(b)[0][0] is a pointer to the very same "big long
> string" - not a copy of the string. So creating the "huge_new_array"
> just creates some new pointers, right? And pointers are very small. So
> for huge_new_array to be a problem, the existence of a and b would
> have
> to have been problematic to start with - meaning that they would
> have to
> have huge length. The amount of *data* in the story (stuff like "big
> long string") is not increased.

not really


cfp:~ > cat a.rb
mb = 2 ** 20

big = 2 * mb

a = Array.new big
b = a.dup

memory_usage = `ps -o rss= -p #{Process.pid}`.to_i
puts memory_usage

a.zip(b)

memory_usage = `ps -o rss= -p #{Process.pid}`.to_i
puts memory_usage



cfp:~ > ruby a.rb
9616
99104


a @ http://codeforp...
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama




Joel VanderWerf

9/10/2008 7:45:00 PM

0

ara.t.howard wrote:
>
> On Sep 10, 2008, at 1:03 PM, matt neuburg wrote:
>
>> Everything in Ruby is a pointer. If a[0] is a pointer to a "big long
>> string", then a.zip(b)[0][0] is a pointer to the very same "big long
>> string" - not a copy of the string. So creating the "huge_new_array"
>> just creates some new pointers, right? And pointers are very small. So
>> for huge_new_array to be a problem, the existence of a and b would have
>> to have been problematic to start with - meaning that they would have to
>> have huge length. The amount of *data* in the story (stuff like "big
>> long string") is not increased.
>
> not really
>
>
> cfp:~ > cat a.rb
> mb = 2 ** 20
>
> big = 2 * mb
>
> a = Array.new big
> b = a.dup
>
> memory_usage = `ps -o rss= -p #{Process.pid}`.to_i
> puts memory_usage
>
> a.zip(b)
>
> memory_usage = `ps -o rss= -p #{Process.pid}`.to_i
> puts memory_usage

It's less dramatic when the entries are not nil (or fixnum etc)--I think
that's Matt's point.

mb = 2 ** 20

big = 2 * mb

a = Array.new big do |i| "the string for entry #{i}" end
b = a.dup

memory_usage = `ps -o rss= -p #{Process.pid}`.to_i
puts memory_usage

a.zip(b)

memory_usage = `ps -o rss= -p #{Process.pid}`.to_i
puts memory_usage

__END__
213256
322232


--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

ara.t.howard

9/10/2008 8:07:00 PM

0


On Sep 10, 2008, at 1:45 PM, Joel VanderWerf wrote:

> It's less dramatic when the entries are not nil (or fixnum etc)--I
> think that's Matt's point.
>
> mb = 2 ** 20
>
> big = 2 * mb
>
> a = Array.new big do |i| "the string for entry #{i}" end
> b = a.dup
>
> memory_usage = `ps -o rss= -p #{Process.pid}`.to_i
> puts memory_usage
>
> a.zip(b)
>
> memory_usage = `ps -o rss= -p #{Process.pid}`.to_i
> puts memory_usage
>
> __END__
> 213256
> 322232

true enough - my point is that the block form is much better when the
arrays are big, without it the new array, pointers or not, is created.

cheers.

a @ http://codeforp...
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama




matt

9/11/2008 5:22:00 PM

0

ara.t.howard <ara.t.howard@gmail.com> wrote:

> On Sep 10, 2008, at 1:45 PM, Joel VanderWerf wrote:
>
> > It's less dramatic when the entries are not nil (or fixnum etc)--I
> > think that's Matt's point.
> >
> > mb = 2 ** 20
> >
> > big = 2 * mb
> >
> > a = Array.new big do |i| "the string for entry #{i}" end
> > b = a.dup
> >
> > memory_usage = `ps -o rss= -p #{Process.pid}`.to_i
> > puts memory_usage
> >
> > a.zip(b)
> >
> > memory_usage = `ps -o rss= -p #{Process.pid}`.to_i
> > puts memory_usage
> >
> > __END__
> > 213256
> > 322232
>
> true enough - my point is that the block form is much better when the
> arrays are big, without it the new array, pointers or not, is created.

Definitely relevant, too, since the block form is quite sufficient for
the OP's original purpose (and similar stuff where the goal is to
process one array in the light of another); thx for bringing out that
point. m.

--
matt neuburg, phd = matt@tidbits.com, http://www.tidbits...
Leopard - http://www.takecontrolbooks.com/leopard-custom...
AppleScript - http://www.amazon.com/gp/product/...
Read TidBITS! It's free and smart. http://www.t...