In the past, I've asked a
couple of times
about
how you design algorithms. Of course, I'm not talking about algorithms with obvious solutions
or those which are already well-known.
Lately, I've been working on a project that I can't share too much about, where we're exploring what is, to
my knowledge, mostly virgin territory. One thing I have learned that I
can share, is something about algorithm design.
It seems obvious to me now, and may be to you, but before recently, I had never thought about it: you can use an iterative approach in designing new algorithms. In the past, I had thought the opposite - since as a unit, the algorithm would rarely have the ability to be broken into chunks for testing purposes, how could we break it into chunks for iteration purposes?
But with the latest one we've been working on, we were able to take an iterative approach in it's design.
The process went something like this:
- Decide what it is you need to accomplish - not necessarily how to accomplish it.
- Based on that, find the parameters to the algorithm that will vary in each invocation.
- Fix the parameters, and run through the algorithm. This will be it's simplest version.
- Go ahead and write it if you want - but be aware it will likely change dramatically between now and when you are finished.
- For each parameter p, vary it and go through the algorithm keeping the rest of the
parameters fixed.
- When you've got that working, now you can start varying combinations of parameters.
Always observe what your algorithm is outputting versus expected output, and
fix it when it's wrong.
- Finally, allow all the parameters to vary as they would in working conditions.
- Clean it up, keeping its essence.
A final bit of advice: don't force looping when the code won't go there. The code
I was working on could have had any number of nested loops, and I spent a long time trying to find the relationships behind the parameters and their depth in the loop structure, in an
attempt to find a way to fix the number of loops (so we don't have to change the code each time
we need another loop in the nest). It was quickly becoming a hard-to-understand mess.
Instead, take a few minutes to step back and look at it from a distance. Do you really need to be looping? In
my case, not as much as I thought.
Use recursion when the code wants to be recursive. (If you still really want to avoid recursion, you'll probably need to simulate it with your own stack - but why do all the extra work?)
That iterative approach to algorithm design worked for me. It turned what at first seemed like a daunting, complicated algorithm into just several lines of elegant, understandable code.
Do you have an approach to designing algorithms whose solutions you don't know (and to be clear - can't find via search)?
Hey! Why don't you make your life easier and subscribe to the full post
or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate
wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!
Leave a comment
so interesting good ideas
Posted by teche
on Jun 22, 2016 at 03:25 AM UTC - 5 hrs
Leave a comment
