Is it possible, a fully general Enumerable#recursive ?
in [Ruby]
|
From: Intransition on 12 Apr 2010 12:01 On Apr 12, 11:08 am, Robert Klemme <shortcut...(a)googlemail.com> wrote: > I don't really understand why this thread seems to be so complicated. > I suspect that either I am missing something or not understanding > properly, or other contributors to this thread are missing something. > :-) I think I see what the confusion is. Your version of recursive looses all the nested structure of the original. And so works fine for most cases, as long that is what one wants/expects. I've been trying to do it such that the nested structure stays intact. e.g. [3,2,1,[6,5,4,[9,8,7]].recursive.sort #=> [1,2,3,[4,5,6,[7,8,9]] Your method produces: [3,2,1,[6,5,4,[9,8,7]].recursive.sort #=> [1,2,3,4,5,6,7,8,9] The former proves much more difficult.
From: Caleb Clausen on 12 Apr 2010 13:00 > On Apr 12, 11:08 am, Robert Klemme <shortcut...(a)googlemail.com> wrote: > >> I don't really understand why this thread seems to be so complicated. >> I suspect that either I am missing something or not understanding >> properly, or other contributors to this thread are missing something. >> :-) I find this subject extremely confusing. Colin's answer to my last email is still causing me puzzlement. On 4/12/10, Intransition <transfire(a)gmail.com> wrote: > I think I see what the confusion is. Your version of recursive looses > all the nested structure of the original. And so works fine for most > cases, as long that is what one wants/expects. I've been trying to do > it such that the nested structure stays intact. e.g. > > [3,2,1,[6,5,4,[9,8,7]].recursive.sort #=> [1,2,3,[4,5,6,[7,8,9]] > > Your method produces: > > [3,2,1,[6,5,4,[9,8,7]].recursive.sort #=> [1,2,3,4,5,6,7,8,9] > > The former proves much more difficult. Yeah, Intransition's way is what I understood to be the point of this thread.... Intransition, how would you handle this: [9,8,7,[6,5,4,[3,2,1]].recursive.sort #=> [1,2,3,[4,5,6,[7,8,9]] Clearly possible, but I have trouble seeing how you're going to make that happen easily. I have often found that too much recursion is confusing. 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...)
From: Robert Dober on 12 Apr 2010 13:37 On Mon, Apr 12, 2010 at 5:08 PM, Robert Klemme <shortcutter(a)googlemail.com> wrote: > 2010/4/12 Robert Dober <robert.dober(a)gmail.com>: >> On Sun, Apr 11, 2010 at 10:55 PM, Robert Klemme >> <shortcutter(a)googlemail.com> wrote: >>> On 04/09/2010 08:53 PM, Intransition wrote: >>>> >>>> On Apr 9, 2:03 pm, Robert Dober <robert.do...(a)gmail.com> wrote: >> eed 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. >> #each takes care of structure #<=> takes care of order, IOW > > As far as I understand the initial posting of this thread the whole > point is to create "something" (aka an Enumerator) whose #each method > recursively iterates through nested Enumerables. This implies that > during that iteration only elements inside Enumerables are yielded > which are not Enumerable. Hence there is no need to provide a > generalized <=> because x.recursive.sort only ever sees those non > Enumerable elements. Of course, sort only can work properly if all > elements have the same type, are compare compatible or an explicit > comparison block is passed to #sort. > >> #recursive is called from #each, or did I miss something here? > > Technically speaking yes, but more correct would be to say that > #recursive is invoked from #recursive. (=> my implementation for an > example) Ok I see what you mean now. I polluted my answer with how I would implement the thing, but I am not here to lecture anyone, it is just my style shining through. > > I don't really understand why this thread seems to be so complicated. > I suspect that either I am missing something or not understanding > properly, or other contributors to this thread are missing something. > :-) IMHO because the rationale is not very clear, but I thought I could help on one tiny point nonetheless, maybe OP is just experimenting and finding out what (s)he wants, fair enough I'd say Cheers R. > > Kind regards > > robert > > -- > remember.guy do |as, often| as.you_can - without end > http://blog.rubybestpractices.com/ > > -- Learning without thought is labor lost; thought without learning is perilous. --- Confucius
From: Robert Klemme on 12 Apr 2010 16:21 On 04/12/2010 07:00 PM, Caleb Clausen wrote: >> On Apr 12, 11:08 am, Robert Klemme <shortcut...(a)googlemail.com> wrote: >> >>> I don't really understand why this thread seems to be so complicated. >>> I suspect that either I am missing something or not understanding >>> properly, or other contributors to this thread are missing something. >>> :-) > > I find this subject extremely confusing. Colin's answer to my last > email is still causing me puzzlement. :-) > On 4/12/10, Intransition <transfire(a)gmail.com> wrote: >> I think I see what the confusion is. Your version of recursive looses >> all the nested structure of the original. And so works fine for most >> cases, as long that is what one wants/expects. I've been trying to do >> it such that the nested structure stays intact. e.g. >> >> [3,2,1,[6,5,4,[9,8,7]].recursive.sort #=> [1,2,3,[4,5,6,[7,8,9]] >> >> Your method produces: >> >> [3,2,1,[6,5,4,[9,8,7]].recursive.sort #=> [1,2,3,4,5,6,7,8,9] >> >> The former proves much more difficult. > > Yeah, Intransition's way is what I understood to be the point of this > thread.... Probably because he is the OP. :-) > Intransition, how would you handle this: > [9,8,7,[6,5,4,[3,2,1]].recursive.sort #=> [1,2,3,[4,5,6,[7,8,9]] > > Clearly possible, but I have trouble seeing how you're going to make > that happen easily. The question is: is this desirable? How do you compare a collection with individual values etc.? You also cannot easily provide a block to #sort because then you need might have to do complex type differentiations etc. > I have often found that too much recursion is confusing. 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...) I also start getting doubts whether all this is a good idea - either my way or Tom's way. My way suffers from loss of structure information as well as it requires compatible types as leaves on all levels. His way makes sorting difficult since you do not have a uniform type any more. It's probably better to provide classes for the nesting on a case by case basis. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
From: Colin Bartlett on 16 Apr 2010 17:20
On Mon, Apr 12, 2010 at 6:00 PM, Caleb Clausen <vikkous(a)gmail.com> wrote: >> On Apr 12, 11:08 am, Robert Klemme <shortcut...(a)googlemail.com> wrote: >>> I don't really understand why this thread seems to be so complicated. >>> I suspect that either I am missing something or not understanding >>> properly, or other contributors to this thread are missing something. >>> :-) Colin's comment: Or possibly both apply? (I think that's true for me! :-)) > 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. Does the following reduce the puzzlement? Taking point (2) of my "puzzling" post first, I was trying to say that I didn't think that there was a bug for two - or rather one and a half - reasons. The full reason, rewording (2): I think (at least with hindsight: I'm not sure that I would think this if I was looking at the documentation and code without this thread prompting it) Tom's code was producing the behaviour expected according to the Ruby 1.9 documentation: that is Enumerable:map returns a "flat" array built up from successive elements yielded from an iteration, and that the Enumerable:map returned array will be "flat" (and is intended to be "flat") even if the underlying iteration is recursive. The half reason is that as I understand it, the basic behavior of Enumerator and Enumerable assumes that the underlying iteration stream is "flat". You can set up a recursive iteration, and use that with Enumerator and Enumerable, but the recursion is hidden from Enumerator/Enumerable. So the "expected" behaviour from an Enumerator/Enumerable method is similar to what you'd expect from running the method against a flat array. (If anyone knows different, *please* correct that.) So, turning to (1), I think the question is not: why is array.visit.map flattening the result? but rather: why is array.visit{block} preserving the nesting in the array? What I was trying to say was that because Tom (I think correctly for what he was wanting to do) was using Array#map inside his recursive iterator, then internally to the iterator the nesting structure of the arrays was preserved (but that for reasons I didn't understand with values changed to nil), but that also internally a "flat" array of the iterated elements (possibly with different values from the returned value from the yield) was being built up, and that for Enumerable#map it is that "flat" array that is returned. Does that help in any way? > 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! > 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! |