From: Marcel Ward Date: 2007-04-09T23:09:08+09:00 Subject: Re: Getting to 100 (#119) On 09/04/07, Rick DeNatale wrote: > On 4/8/07, Marcel Ward wrote: > > On 08/04/07, Carl Porth wrote: > > > After going back and reading the current solutions, I like Ken Bloom's > > > each_partition method. It's much cleaner than my combinations method. > > > > I agree, very clean and efficient. The three lines that put it all > > together using #zip are what makes this work for me: > > > > Digits.each_partition(Operators.length+1) do |digitspart| > > OperatorPerms.each do |operatorsperm| > > expression=digitspart.zip(operatorsperm).flatten.join > > ... > > > > I think I would be feeling very happy if I'd submitted this solution :) > > May I have the temerity to point out that I posted basically the same > solution, which I posted two hours before Ken's. Indeed you may -- apologies, I thought I had been back through all the posts but didn't go back as far as yours. So I think you should also be feeling very happy :) I do have one small piece of constructive criticism (if I may) since you brought attention to your code: found = val == goal puts "*****************" if found_in_a_row == 0 && found puts "*****************" unless found_in_a_row == 0 || found puts "#{eqn} = #{val}" if verbose || goal == val found_in_a_row = found ? found_in_a_row + 1 : 0 Could also have been written: found = val == goal puts "*****************" if found puts "#{eqn} = #{val}" if verbose || goal == val puts "*****************" if found found_in_a_row = found ? found_in_a_row + 1 : 0 For the same number of lines, I find the second much easier to follow without having to remember any state for the second time around. There does not seem to be any advantage in placing the asterisk lines together. (?) As another aside, I'm in two minds as to whether it's necessary to provide such a complete set of parameters (and comments) for these solutions. On the one hand it sets a good example to newcomers (and it satisfies our quest for perfection) but on the other it does tend to obscure some of the more interesting details. It's like you're damned if you do and damned if you don't - the difficulty is finding the right balance. I think there's room for both kinds of posts but certainly the shorter ones seem more appealing even if longer ones do use the same underlying methods. I also like to work at making a solution more generic for future purposes but I've come to the conclusion that (unless the extra credits mention it) there's no point because I'm only going to prejudice my solution. In the real world I would go for the more generic code and proper comments any day but for the purposes of the quiz I like to see solutions that do just as much as is asked of them and ideally fit on one page of my screen. -- Marcel > -- > Rick DeNatale > > My blog on Ruby > http://talklikeaduck.denhaven2.com/