In my work, I try to follow common software development principles. Thus, I first analyze the 'needs' and then the 'means'. The former entails client specifications and requirements, whereas the latter includes the 'fun' part: design, coding, implementation, testing etc. The part you are aquiring about falls between the 'design' and 'coding' stages. Algorithm design is made much easier provided more abstract design was given due attention.

A good case in point is Damian Conway's work on the Parse::FastDescent module. In his April 5, 2002 diary entry he stresses the importance of talking your design over with other clever developers on your team. Also, a lot of useful examples could be drawn from the way development of Perl 6 is approached. One that immediately springs to my mind is that there's always a lot of outside input on any given piece of Perl 6 design. Such discussions is the key to assuring that your future design will cover all the rough edges etc.

Armed with a good (abstract) design, writing algorithms is made much easier. Certainly, algorithms can be either too abstract or detailed. In building my algorithm, I always attempt to follow through with a 'top-down' design principle. I would first design (discuss, test, etc.) abstract program algorithm that are concerned with the 'overall' work of my code, and only than concentrate on specific areas.

I should also mention that design of your supporting data structures is integral to optimal and dependable algorithms. If little thought and effort is given to the design of your program's data structures, eventually your algorithm will reflect that. In my life, I have met programs which had their data structured in a sloppy or even haphazard way. Consequently, overall program flow seemed to suffer extensively. Here and there, I would notice serious lapses in program logic. It almost seemed as if the original author had gone through extreme pains to wrap his/her program code around its poorly designed data structures.

UPDATE: was compelled to add another paragraph to further my point somewhat ;-)

_____________________ 
$"=q;grep;;$,=q"grep";for(`find . -name ".saves*~"`){s;$/;;;/(.*-(\d+)
+-.*)$/;
$_=["ps -e -o pid | "," $2 | "," -v "," "];`@$_`?{print"+ $1"}:{print"
+- $1"}&&`rm $1`;
print$\;}

[download]

In reply to Re: Algorithm design by vladb
in thread Algorithm design by Phemur

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.