Is it possible, a fully general Enumerable#recursive ?
in [Ruby]
|
From: Robert Dober on 16 Apr 2010 17:44 On Fri, Apr 16, 2010 at 11:20 PM, Colin Bartlett <colinb2r(a)googlemail.com> wrote: <snip> > "After working on this for far too long, I have concluded that > a highly generalized implementation of recursion for all > (or at least most) enumerable methods not feasible.") I beg to differ module Enumerable def recursive_each &blk each do | ele | Enumerable === ele ? ele.recursive_each(&blk) : blk[ele] end end def rec_enum; enum_for :recursive_each end end x=[ :a, 42, [:b, :c], {:a=> 42, :b => [1,2]}] rx = x.rec_enum p rx.to_a p rx.any?{ |x| x > 41 rescue false } p rx.map{ |x| "<#{x}>" }.join(", ") Cheers R. -- The best way to predict the future is to invent it. -- Alan Kay
From: Caleb Clausen on 16 Apr 2010 19:17 On 4/16/10, Colin Bartlett <colinb2r(a)googlemail.com> wrote: > On Mon, Apr 12, 2010 at 6:00 PM, Caleb Clausen <vikkous(a)gmail.com> wrote: >> I find this subject extremely confusing. >> Colin's answer to my last email is still causing me puzzlement. > Two apologies: first, for not replying sooner to this. > (I was going to do a combined response to this and to what Tom and Robert > have said, hence the delay: I then decided that it would be better > to make a reply to you on this specific point, and follow up later > with more general observations. I think I've nearly got a proof of concept > thing working. That said, I - for now - still agree with Tom's comment: > "After working on this for far too long, I have concluded that > a highly generalized implementation of recursion for all > (or at least most) enumerable methods not feasible.") > > Second, sorry for causing puzzlement. I (mostly) try not to be > deliberately obfuscatory. Was it (1) or (2) (or both!) > of my reply to your post that was/is causing puzzlement? > > (1) Using #map inside #visit combined with using Enumerable#map > seems to (within #visit) produce the structure of the original array, > but with nil values instead of the original values. > (Changing #map inside #visit to #each gets back the original values.) > > (2) Irrespective of the internal results from #visit, Enumerable#map > collects the successive results of the block for Enumerable#map > into a new (flat) array. It's more like: (3) Too much recursion just makes my brain hurt. It's not really your failing... I just have difficulty understanding these things. It's not like your code was particularly complicated, but I couldn't keep all the implications straight in my head. > Does the following reduce the puzzlement? [snip] > Does that help in any way? Yes, some. Thanks for the explanation >> I have often found that too much recursion is confusing. > Yes - me too! My test version of a "general" recursive enumerator > looks more like C (or Fortran!) code than Ruby. > I sort of instinctively think in terms of what's underlying the recursion, > which can get in the way of me just using recursion, > when just using recursion might well be easier! Ah, good. I'm glad I'm not the only one. There's a good reason why I refuse outright to look seriously at functional languages. >> This whole problem is going to be a lot easier if it's structured >> as an external iterator first and foremost. >> I have an extern iterator library (sequence) >> maybe I can figure out how to do this within that. >> (I don't really have a good grip on how Enumerator works, myself...) > > Provided I understand more or less correctly what you mean by > an "extern iterator library", then it might be something that > I could understand! Basically, external iterator == no recursion. Enumerator is an external iterator. I'm still trying to work out (in my copious free time, hah!) how this would work and if it's worth it. An external iterator has to keep an 'index' internally so it knows where it is in the data structure. In this case, the 'index' is not a simple integer, its something more like an xpath. On 4/16/10, Robert Dober <robert.dober(a)gmail.com> wrote: > On Fri, Apr 16, 2010 at 11:20 PM, Colin Bartlett > <colinb2r(a)googlemail.com> wrote: > <snip> >> "After working on this for far too long, I have concluded that >> a highly generalized implementation of recursion for all >> (or at least most) enumerable methods not feasible.") > I beg to differ > module Enumerable > def recursive_each &blk > each do | ele | > Enumerable === ele ? ele.recursive_each(&blk) : blk[ele] > end > end > > def rec_enum; enum_for :recursive_each end > end > > x=[ :a, 42, [:b, :c], {:a=> 42, :b => [1,2]}] > > rx = x.rec_enum > > p rx.to_a > p rx.any?{ |x| x > 41 rescue false } > p rx.map{ |x| "<#{x}>" }.join(", ") Sorry, but: y=[9,8,7,[6,5,4,[1,2,3]]] ry=y.rec_enum ry.sort #=> [1, 2, 3, 4, 5, 6, 7, 8, 9], should be [1,2,3,[4,5,6,[7,8,9]]]
From: Intransition on 16 Apr 2010 21:23 On Apr 16, 5:44 pm, Robert Dober <robert.do...(a)gmail.com> wrote: > On Fri, Apr 16, 2010 at 11:20 PM, Colin Bartlett<colin...(a)googlemail.com> wrote: > > <snip>> "After working on this for far too long, I have concluded that > > a highly generalized implementation of recursion for all > > (or at least most) enumerable methods not feasible.") > > I beg to differ > module Enumerable > def recursive_each &blk > each do | ele | > Enumerable === ele ? ele.recursive_each(&blk) : blk[ele] > end > end > > def rec_enum; enum_for :recursive_each end > end > > x=[ :a, 42, [:b, :c], {:a=> 42, :b => [1,2]}] > > rx = x.rec_enum > > p rx.to_a > p rx.any?{ |x| x > 41 rescue false } > p rx.map{ |x| "<#{x}>" }.join(", ") Yes and no. See my previous post about preserving structure.
From: Robert Dober on 16 Apr 2010 21:37 On Sat, Apr 17, 2010 at 1:17 AM, Caleb Clausen <vikkous(a)gmail.com> wrote: > On 4/16/10, Colin Bartlett <colinb2r(a)googlemail.com> wrote: >> On Mon, Apr 12, 2010 at 6:00 PM, Caleb Clausen <vikkous(a)gmail.com> wrote: >>> I find this subject extremely confusing. >>> Colin's answer to my last email is still causing me puzzlement. >> Two apologies: first, for not replying sooner to this. >> (I was going to do a combined response to this and to what Tom and Robert >> have said, hence the delay: I then decided that it would be better >> to make a reply to you on this specific point, and follow up later >> with more general observations. I think I've nearly got a proof of concept >> thing working. That said, I - for now - still agree with Tom's comment: >> "After working on this for far too long, I have concluded that >> a highly generalized implementation of recursion for all >> (or at least most) enumerable methods not feasible.") >> >> Second, sorry for causing puzzlement. I (mostly) try not to be >> deliberately obfuscatory. Was it (1) or (2) (or both!) >> of my reply to your post that was/is causing puzzlement? >> >> (1) Using #map inside #visit combined with using Enumerable#map >> seems to (within #visit) produce the structure of the original array, >> but with nil values instead of the original values. >> (Changing #map inside #visit to #each gets back the original values.) >> >> (2) Irrespective of the internal results from #visit, Enumerable#map >> collects the successive results of the block for Enumerable#map >> into a new (flat) array. > > It's more like: > (3) Too much recursion just makes my brain hurt. > > It's not really your failing... I just have difficulty understanding > these things. It's not like your code was particularly complicated, > but I couldn't keep all the implications straight in my head. > > >> Does the following reduce the puzzlement? > [snip] >> Does that help in any way? > > Yes, some. Thanks for the explanation > >>> I have often found that too much recursion is confusing. >> Yes - me too! My test version of a "general" recursive enumerator >> looks more like C (or Fortran!) code than Ruby. >> I sort of instinctively think in terms of what's underlying the recursion, >> which can get in the way of me just using recursion, >> when just using recursion might well be easier! > > Ah, good. I'm glad I'm not the only one. There's a good reason why I > refuse outright to look seriously at functional languages. > >>> This whole problem is going to be a lot easier if it's structured >>> as an external iterator first and foremost. >>> I have an extern iterator library (sequence) >>> maybe I can figure out how to do this within that. >>> (I don't really have a good grip on how Enumerator works, myself...) >> >> Provided I understand more or less correctly what you mean by >> an "extern iterator library", then it might be something that >> I could understand! > > Basically, external iterator == no recursion. Enumerator is an > external iterator. > > I'm still trying to work out (in my copious free time, hah!) how this > would work and if it's worth it. An external iterator has to keep an > 'index' internally so it knows where it is in the data structure. In > this case, the 'index' is not a simple integer, its something more > like an xpath. > > On 4/16/10, Robert Dober <robert.dober(a)gmail.com> wrote: >> On Fri, Apr 16, 2010 at 11:20 PM, Colin Bartlett >> <colinb2r(a)googlemail.com> wrote: >> <snip> >>> "After working on this for far too long, I have concluded that >>> a highly generalized implementation of recursion for all >>> (or at least most) enumerable methods not feasible.") >> I beg to differ >> module Enumerable >> def recursive_each &blk >> each do | ele | >> Enumerable === ele ? ele.recursive_each(&blk) : blk[ele] >> end >> end >> >> def rec_enum; enum_for :recursive_each end >> end >> >> x=[ :a, 42, [:b, :c], {:a=> 42, :b => [1,2]}] >> >> rx = x.rec_enum >> >> p rx.to_a >> p rx.any?{ |x| x > 41 rescue false } >> p rx.map{ |x| "<#{x}>" }.join(", ") > > Sorry, but: > > y=[9,8,7,[6,5,4,[1,2,3]]] > ry=y.rec_enum > ry.sort #=> [1, 2, 3, 4, 5, 6, 7, 8, 9], should be [1,2,3,[4,5,6,[7,8,9]]] > > Why? What is the purpose of rec_enum then? R. -- The best way to predict the future is to invent it. -- Alan Kay
From: apeiros on 17 Apr 2010 06:48
Am 12.04.2010 um 17:51 schrieb Intransition: > On Apr 11, 4:55 pm, Robert Klemme <shortcut...(a)googlemail.com> wrote: > >>>> However you will need to define #<=> on the return value of recursive. >> >> Why that? The whole point would be to sort all elements that would be >> recursively returned. The #recursive return value would never be seen then. > > Do you run into the issue of sorting [1,2,3, [:a,:b,:c]] where by an > error is raised when it tries, 1 <=> [:a,:b,:c] ? How does recursively sorting [1,2,3, [:a,:b,:c]] make any sense? That's just as broken as trying to sort [:a, "b", 3, Time.now] - those values are not comparable and sort will raise. I can see sorting e.g. [[2,5,4],[3,2,1]] recursively making sense, though, the result being [[1,2,3],[2,4,5]]. But the above should just raise, anything else makes IMO no sense. Regards Stefan |