https://redmine.ruby-lang.org/https://redmine.ruby-lang.org/favicon.ico?17113305112012-07-29T01:35:28ZRuby Issue Tracking SystemRuby master - Feature #6808: Implicit index for enumerationshttps://redmine.ruby-lang.org/issues/6808?journal_id=285102012-07-29T01:35:28Ztrans (Thomas Sawyer)
<ul></ul><p>Ixnay on the global variable. It was just pointed out to me that it would be problem for nested iterations. Keyword could still work though b/c it would be block local.</p> Ruby master - Feature #6808: Implicit index for enumerationshttps://redmine.ruby-lang.org/issues/6808?journal_id=285212012-07-29T08:53:15Zcjheath (Clifford Heath)clifford.heath@gmail.com
<ul></ul><p>The inconsistency between operations over Arrays and Hashes isn't always avoidable, but consider:</p>
<p>h = Hash[1, 2, 3, 4, 5, 6]<br>
a = [1, 2, 3, 4, 5, 6]</p>
<p>h[3]<br>
=> 4<br>
h.detect{|k, v| k == 3 }<br>
#=> [3, 4]</p>
<p>a[3]<br>
#=> 3<br>
a.detect{|v| v == 3 }<br>
#=> 3</p>
<p>Surely the block passed to Array#detect should receive the index, and<br>
the result of a Hash#detect should be a value, not a [key, value] pair?</p>
<p>I don't expect this to be changed, but perhaps it might inform proposed changes.</p>
<p>Clifford Heath.</p> Ruby master - Feature #6808: Implicit index for enumerationshttps://redmine.ruby-lang.org/issues/6808?journal_id=285502012-07-31T04:30:22Zdrbrain (Eric Hodel)drbrain@segment7.net
<ul></ul><p>What about the overhead for an infinite enumerator that does not use the implicit index? Especially after a few days of CPU time for a frequently-used enumerator?</p> Ruby master - Feature #6808: Implicit index for enumerationshttps://redmine.ruby-lang.org/issues/6808?journal_id=285522012-07-31T06:09:48Ztrans (Thomas Sawyer)
<ul></ul><p><a class="user active user-mention" href="https://redmine.ruby-lang.org/users/47">@drbrain (Eric Hodel)</a> It's a fair point. But I imagine the index already exists under the hood. Probably the question is, can it be made accessible with little overhead?</p>
<p>Perhaps <code>it</code> could even be partially lazy, so full overhead doesn't even come into play unless used.</p> Ruby master - Feature #6808: Implicit index for enumerationshttps://redmine.ruby-lang.org/issues/6808?journal_id=285532012-07-31T06:37:24Zdrbrain (Eric Hodel)drbrain@segment7.net
<ul></ul><p>There is no such index internal to Enumerator to make accessible.</p>
<p>each_with_index already exists to do this. The use of each_with_index is preferable to an implicit, lazy iteration count. The former is intention-revealing while the latter is not.</p>
<p>For this new feature a user may ask, "Where does this local variable come from? I didn't assign to it!" or, "Why was my 'it' (or 'index') variable overwritten with a number?" each_with_index does not have either of these problems.</p> Ruby master - Feature #6808: Implicit index for enumerationshttps://redmine.ruby-lang.org/issues/6808?journal_id=285542012-07-31T07:59:41Ztrans (Thomas Sawyer)
<ul></ul><blockquote>
<p>There is no such index internal to Enumerator to make accessible.</p>
</blockquote>
<p>It not about Enumerator, its about #each itself. And there certainly is and index with #each method itself. e.g. <a href="https://github.com/ruby/ruby/blob/trunk/array.c#L1549" class="external">https://github.com/ruby/ruby/blob/trunk/array.c#L1549</a></p>
<p>#each_with_index doesn't cut it at all, as it doesn't address all the other possibilities, #map_with_index, #select_with_index, etc., which is the point.</p>
<p>I really don't see the problem with "I didn't assign that". If its spec its expected, and we already have this sort of thing with regexp globals.</p> Ruby master - Feature #6808: Implicit index for enumerationshttps://redmine.ruby-lang.org/issues/6808?journal_id=285562012-07-31T08:23:43ZAnonymous
<ul></ul><p>On Jul 30, 2012, at 6:59 PM, trans (Thomas Sawyer) <a href="mailto:transfire@gmail.com" class="email">transfire@gmail.com</a> wrote:</p>
<blockquote>
<p>Issue <a class="issue tracker-2 status-7 priority-4 priority-default closed" title="Feature: Implicit index for enumerations (Feedback)" href="https://redmine.ruby-lang.org/issues/6808">#6808</a> has been updated by trans (Thomas Sawyer).</p>
<blockquote>
<p>There is no such index internal to Enumerator to make accessible.</p>
</blockquote>
<p>It not about Enumerator, its about #each itself. And there certainly is and index with #each method itself. e.g. <a href="https://github.com/ruby/ruby/blob/trunk/array.c#L1549" class="external">https://github.com/ruby/ruby/blob/trunk/array.c#L1549</a></p>
</blockquote>
<p>But that's only each for arrays. I doubt an each method for, say, linked lists would bother to implement an internal index.</p>
<blockquote>
<p>#each_with_index doesn't cut it at all, as it doesn't address all the other possibilities, #map_with_index, #select_with_index, etc., which is the point.</p>
</blockquote>
<p>I'm not clear why the #with_index method isn't adequate for your needs.</p>
<p>[1,2,3].map.with_index { |item, index| [item, index] }</p>
<p>--<br>
-- Jim Weirich<br>
-- <a href="mailto:jim.weirich@gmail.com" class="email">jim.weirich@gmail.com</a></p> Ruby master - Feature #6808: Implicit index for enumerationshttps://redmine.ruby-lang.org/issues/6808?journal_id=285662012-07-31T14:20:56Ztrans (Thomas Sawyer)
<ul></ul><p>=begin</p>
<blockquote>
<p>I'm not clear why the #with_index method isn't adequate for your needs.</p>
</blockquote>
<p>Yes, functionally your are right. I was just thinking that the overall overhead would be less if enumerator wasn't used. I ran some benchmarks: <a href="https://gist.github.com/3213779" class="external">https://gist.github.com/3213779</a></p>
<a name="EACH-user-system-total-real"></a>
<h1 >EACH user system total real<a href="#EACH-user-system-total-real" class="wiki-anchor">¶</a></h1>
<p>each 3.840000 0.010000 3.850000 ( 3.843590)<br>
enumerator each 5.130000 0.020000 5.150000 ( 5.156704)<br>
each_with_index 5.650000 0.020000 5.670000 ( 5.662425)<br>
each and manual index 5.190000 0.010000 5.200000 ( 5.206394)<br>
enumerator each.with_index 6.500000 0.020000 6.520000 ( 6.519111)<br>
enumerator each and manual index 6.480000 0.020000 6.500000 ( 6.501582)</p>
<a name="MAP-user-system-total-real"></a>
<h1 >MAP user system total real<a href="#MAP-user-system-total-real" class="wiki-anchor">¶</a></h1>
<p>map 5.210000 0.020000 5.230000 ( 5.230273)<br>
enumerator map 9.450000 0.040000 9.490000 ( 9.491262)<br>
map and manual index 6.600000 0.020000 6.620000 ( 6.629977)<br>
enumerator map.with_index 8.270000 0.030000 8.300000 ( 8.291350)<br>
enumerator map and manual index 11.210000 0.050000 11.260000 ( 11.256445)</p>
<p>Notice the results of the manual index without the enumerator --and that's in Ruby, not C code.<br>
=end</p> Ruby master - Feature #6808: Implicit index for enumerationshttps://redmine.ruby-lang.org/issues/6808?journal_id=285682012-07-31T16:16:23Zdrbrain (Eric Hodel)drbrain@segment7.net
<ul></ul><p>trans (Thomas Sawyer) wrote:</p>
<blockquote>
<blockquote>
<p>I'm not clear why the #with_index method isn't adequate for your needs.</p>
</blockquote>
<p>Yes, functionally your are right. I was just thinking that the overall overhead would be less if enumerator wasn't used. I ran some benchmarks: <a href="https://gist.github.com/3213779" class="external">https://gist.github.com/3213779</a></p>
<p>[…]</p>
<p>Notice the results of the manual index without the enumerator --and that's in Ruby, not C code.</p>
</blockquote>
<p>Are the times of these benchmarks dominated by object creation or iteration? What happens if you run a small number of trials across a large array? (n = 26, a = (0...1000000).to_a)</p>
<p>No matter which method is faster, what happens to this code:</p>
<p>index = 10<br>
offsets.each do |e|<br>
index = e if condition e<br>
break if index > 30<br>
end</p>
<p>Does index equal 10 on the first execution of the block? Does it equal 0?</p> Ruby master - Feature #6808: Implicit index for enumerationshttps://redmine.ruby-lang.org/issues/6808?journal_id=286002012-08-02T23:00:25Ztrans (Thomas Sawyer)
<ul></ul><p>=begin</p>
<blockquote>
<p>Are the times of these benchmarks dominated by object creation or iteration? What happens if you run a small number of trials across a large array? (n = 26, a = (0...1000000).to_a)</p>
</blockquote>
<p>You are correct that the difference would be less for large arrays and few iterations.</p>
<a name="EACH-user-system-total-real"></a>
<h1 >EACH user system total real<a href="#EACH-user-system-total-real" class="wiki-anchor">¶</a></h1>
<p>each 3.610000 0.050000 3.660000 ( 3.671551)<br>
enumerator each 3.610000 0.030000 3.640000 ( 3.642515)<br>
each_with_index 4.920000 0.020000 4.940000 ( 4.972732)<br>
each and manual index 4.930000 0.010000 4.940000 ( 4.950868)<br>
enumerator each.with_index 4.950000 0.000000 4.950000 ( 4.982888)<br>
enumerator each and manual index 4.900000 0.000000 4.900000 ( 4.911986)</p>
<a name="MAP-user-system-total-real"></a>
<h1 >MAP user system total real<a href="#MAP-user-system-total-real" class="wiki-anchor">¶</a></h1>
<p>map 4.230000 0.080000 4.310000 ( 4.324616)<br>
enumerator map 6.060000 0.090000 6.150000 ( 6.176046)<br>
map and manual index 5.540000 0.070000 5.610000 ( 5.633096)<br>
enumerator map.with_index 5.510000 0.060000 5.570000 ( 5.568634)<br>
enumerator map and manual index 7.090000 0.200000 7.290000 ( 7.287555)</p>
<p>But the difference looks less pronounced in this case, and on average I think programs tend to create and iterate over more small arrays, then they do large ones.</p>
<blockquote>
<p>No matter which method is faster, what happens to this code:<br>
...<br>
Does index equal 10 on the first execution of the block? Does it equal 0?</p>
</blockquote>
<p>That's a fair question. I think to preserve backward compatibility, this code would have to behave just as you present it. In other words, the implicit index has been overridden by assigning it as a local variable. Which is why originally a global seemed the right choice. But can a global behave block local?</p>
<p>In any case, I think I will withdraw this request. Having to worry about local override or managing global that behaves block local will probably dry up any performance gain. And in retrospect I think the whole <code>it</code> idea, while good on it's face, doesn't really solve the issues it is intended to well.<br>
I'm glad to have had the chance to discuss this and flush it out though, as it has been sitting in the back of my mind for a while.<br>
=end</p> Ruby master - Feature #6808: Implicit index for enumerationshttps://redmine.ruby-lang.org/issues/6808?journal_id=286042012-08-03T03:15:33Zdrbrain (Eric Hodel)drbrain@segment7.net
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li></ul><p>trans (Thomas Sawyer) wrote:</p>
<blockquote>
<blockquote>
<p>No matter which method is faster, what happens to this code:<br>
...<br>
Does index equal 10 on the first execution of the block? Does it equal 0?</p>
</blockquote>
<p>That's a fair question. I think to preserve backward compatibility, this code would have to behave just as you present it. In other words, the implicit index has been overridden by assigning it as a local variable. Which is why originally a global seemed the right choice. But can a global behave block local?</p>
</blockquote>
<p>$~ and friends behave this way (thread and method local).</p>
<blockquote>
<p>In any case, I think I will withdraw this request. Having to worry about local override or managing global that behaves block local will probably dry up any performance gain. And in retrospect I think the whole <code>it</code> idea, while good on it's face, doesn't really solve the issues it is intended to well.</p>
</blockquote>
<p>OK.</p> Ruby master - Feature #6808: Implicit index for enumerationshttps://redmine.ruby-lang.org/issues/6808?journal_id=286062012-08-03T03:48:26Ztrans (Thomas Sawyer)
<ul></ul><blockquote>
<p>$~ and friends behave this way (thread and method local).</p>
</blockquote>
<p>Hmmm... In that case, maybe it is worth trying, to see what the actual performance change would be. I'm willing to do it, and I basically know enough to work with a global variable in the C code. But how to handle block local behavior?</p> Ruby master - Feature #6808: Implicit index for enumerationshttps://redmine.ruby-lang.org/issues/6808?journal_id=286092012-08-03T05:10:11Zdrbrain (Eric Hodel)drbrain@segment7.net
<ul><li><strong>Status</strong> changed from <i>Closed</i> to <i>Feedback</i></li></ul><p>See rb_define_virtual_variable() and vm_svar_get()</p> Ruby master - Feature #6808: Implicit index for enumerationshttps://redmine.ruby-lang.org/issues/6808?journal_id=315302012-10-25T19:18:20Zyhara (Yutaka HARA)
<ul><li><strong>Target version</strong> changed from <i>2.0.0</i> to <i>2.6</i></li></ul> Ruby master - Feature #6808: Implicit index for enumerationshttps://redmine.ruby-lang.org/issues/6808?journal_id=688112017-12-25T18:15:07Znaruse (Yui NARUSE)naruse@airemix.jp
<ul><li><strong>Target version</strong> deleted (<del><i>2.6</i></del>)</li></ul>