On 4/9/07, Marcel Ward <wardies / gmail.com> wrote:
> On 09/04/07, Rick DeNatale <rick.denatale / gmail.com> wrote:

> 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. (?)


Not quite the same I think.  I wrote it the way I did to cover the
(admittedly probably rare case where two solutions occur  one after
the other. That's why the variable found_in_a_row is there.

I wanted to see:

********
  xxxxxx = 100
  yyyyyy = 100
********

instead of


********
  xxxxxx = 100
********
********
  yyyyyy = 100
********


> 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.

I see it as an opportunity to document my thoughts in solving the
quiz, and thereby teach myself and others.  The best way to learn is
to teach.

And, Frankly, I'm kind of an anti-golf advocate, except when I have a
club in my hands instead of a keyboard at my finger-tips.

Finally I figure that it's JEG II's choice as to how to summarize the solutions.

Chacun a son goû¹!

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/