I plan to present a number of Evolutionary Computation (EC) examples in this blog. In order to do that I’d like to create a general purpose EC library in Python that I will call Eclypse. In this post I will outline some of the main goals I have for the design of this library. In a nutshell my top goals are to make the library easily understandable, reconfigurable and extensible. I’ll explain exactly what I mean by these…
As I said, this blog is a place for me to describe some of the things I’ve learned, and explore other things that interest me. That means that Eclypse code must understandable so that readers can follow along. There are two strategies that I intend to use to achieve this goal: brevity and familiarity. I will try to make it possible to write code that is concise (at least at each appropriate level of abstraction), and I will try to avoid programming constructs that may be confusing.
Another important goal is that Eclypse be reconfigurabile. Evolutionary algorithms have a long history of being used on a wide variety of problems, and using a wide variety of different components, such as different genetic representations (i.e. genetic codes) and different reproductive operators (e.g. crossover, mutation, etc). Often, the components that one chooses can have a big effect on the Evolutionary Agorithm’s (EA’s) ability to find good solutions. This means that it’s usually a good idea to experiment with some different configurations to see what effects they have on the results. For this reason, my goal is to make sure that Eclypse allows users to reconfigure these components quickly and easily.
And finally, a key goals is that Eclypse be extensible. Improvements are continually being made to EAs, and it is unlikely that Eclypse will ever implement all of them. Users need to have the ability to add new components whenever necessary. My hope is that many of the strategies that I will use to make Eclypse reconfigurable will also help make it extensible.
There are other factors that are important, of course. Some examples are accuracy and speed. Accuracy isn’t much of an issue these days in most situations, but speed is often a concern for those who are not won over by Python. By default, Python code tends to be significantly slower than similar code in other languages. There are two things I’ve personally noticed about this though. First, I can write code much faster in Python, and I value my time more than the computer’s. And second, code can always be made to run faster by identifying a couple of critically slow functions (using a profiler), and then reimplementing them in a faster language, like C.
The truth is that I have already designed and implemented a precursor Eclypse many years ago while I was working on my Ph.D. dissertation. It was originally called ECLIPSE. Then when the Eclipse IDE was release, I decided to nickname it LEAP (although I never really liked that name) in order to avoid confusion. I’ll discuss the history of these in a future post.