From: William Morgan Date: 2005-03-11T00:41:33+09:00 Subject: Re: Is iterating in lock-step possible? Excerpts from Roshan James's mail of 10 Mar 2005 (EST): > Generators - I did not know about them. I had a look at this - > http://www.ruby-doc.org/stdlib/libdoc/generator/rdoc/classes/Generator.html > > It does not look like this is a good think to do at all, because all the > state-management that itertors do for free is lost at the cost of > creating another continuation around it. I'm not sure what you mean by that, but: > Admittedly this solves the syntactic problem that I was looking for a > solution to, but at a very large cost to the runtime. There's a definite cost to using generators. Of course, you've already incurred a huge performance penalty by using Ruby in the first place. Is the further cost of generators really too much? I see about a factor of ten slow-down in the following toy example. It'd be interesting to do more datapoints and see if this is a linear relationship or what. ruby -rgenerator -rbenchmark -e 'a=(1..100000).map{|x|x};g=Generator.new(a);[ lambda { a.each { |x| x } }, lambda { while g.next?; g.next; end }, ].each {|pr| puts Benchmark.measure(&pr) }' 0.030000 0.000000 0.030000 ( 0.027388) 10.380000 1.190000 11.570000 ( 11.612888) > I found a terse description of zip() at > http://whytheluckystiff.net/articles/rubyOneEightOh.html > Is there a better place I can read up about this? I want to know how > this works. Unfortunately not, other than the Ruby source code itself. > In my post, I chose the array.each only as an example. Its not arrays > for which I want to do this with - I want to solve the problem for > iterator calls. If zip() internally creates a list of values from both > iterations, then it does not help me. I want to be able to do the actual > computation of the iterator calls in lock-step. Enum#zip internally turns everything into arrays. Unless you can deal with the original objects as external (i.e. Python-style) iterators, this is the price you pay for the niceness of interal iterators. -- William