Re: Algorithm design

[vladb]

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$\;}

[webfiend]

Don't forget the additional half-step at each step of your design:
• Examine each required feature
  • Is there a CPAN module that already does this?

...

• Examine each algorithm or data structure in the program design
  • Is there a CPAN module that already does this?

I know, it's just the obvious "don't reinvent the wheel" line. Still, I get carried away with my own (imagined) cleverness sometimes, and had to make this an official part of my routine. If I don't look for pre-existing modules, I don't get to have any more coffee that day. A little self-imposed discipline there :-)

---

"All you need is ignorance and confidence; then success is sure."-- Mark Twain