When looking at each of the past articles on how Genetic Algorithms are designed, one can guess that the code for these things must be quite involved. This programming endeavor is one of those that requires to be designed first. It is very difficult to write your own genetic algorithm without knowing what you're doing.

Probably the most common way of implementing GAs is to use a library. Off-the-shelf libraries are the most logical choice because there is so much code that can be reused. Every operator discussed so far can be used regardless of what the algorithm is solving, so all of that code can be reused. In fact, the beauty of these algorithms is that they lend themselves to so much code reuse, of which libraries are ideal for.

Problems arise, however, when you begin to look at how much flexibility you need. The entire Genetic Algorithm is a bunch of operators working in sequence. There is a huge amount of variations to each operator and each one needs its own set of parameters. Unless you've already had experience with GAs it's hard to understand what direction to take, and even harder to change your mind when things aren't working. That's the hardest part about starting in Genetic Algorithms: they're hard to get started in because they're so tricky to put together the first few times.

One of the main difficulties in programming a Genetic Algorithm is expressing your genomes graphically. Sometimes you'll want to see what a genome looks like so that you can see what kinds of ideas your genome is going through. Or, better yet, maybe you want to see how the best fit genome looks every five generations so that you can see the "thought process" of the algorithm in real time. These are all things that I have decided to do in my projects in order to make the things a bit more exciting, but the issue that must be adressed is that of encapsulation. You need to give your population some sort of mechanism that can give you a genome's data without violating data hiding rules. It's yet another idea that needs to be designed well before you jump into programming.

The verdict is that GAs are difficult programming projects to maintain because of the various modules that need to communicate with each other. One solution to that is to use a library which has most of these small details already worked out. Another solution is to design exactly what you want ahead of time and hard-code it all in.

Simply Beautiful
Genetic Algorithms, in all of their complexities and intricacies, are beautiful. Very rarely are there so many parallels to real life than there are with GAs. The beautiful aspect to me is that, in the end, the GAs do behave similarly to real life in their evolution process. It's like watching evolutionary processes sped up over hundreds of generations. What's even more interesting is that throwing in more factors, like genetic drift, makes the populations grow even better. We are truly taking what we learned from observing the environment around us and simulating it with completely unrelated ideas and making scientific progress. This marriage of Computer Science, Mathematics, and Biology is a huge development in our scientific progress.

Machine Learning: Paradox?
So now this philosophical question arises: are we teaching our computers to "learn"? What is going on to the programmer is a bunch of guesses which are systematically combined and modified to produce a better result, but to the untrained eye it appears that the population is learning how to adapt to its environment. Is it possible that the processes in our brains and in our evolution is simply just a (more) complicated array of operators which somehow make us "learn". In other words, are we in awe of our learning processes because we don't really understand them? Are we just a set of small pieces of atoms functioning in complicated ways, or is there something else going on here? It's an interesting philosophical discussion which has many intricacies along the way.

News | Research | Personal Profile | Photo Album
Contact Me