New Haskell GA library

2012-02-09

I'm hacking on a genetic algorithm library in Haskell in my free time. Initially, I hoped to use the code at work, but I changed the research project and it never happened. Now I intend to bring it to the usable and stable state. Initially, it started as a fork of SimpleEA library, but quickly departed for a different design. It will not cover all evolutionary algorithms, only genetic ones, but it is intended to be serious and flexible (read: not really simple). Hence, the fork. The library is slowly taking shape, and already offers some features that many other open source GA libraries do not.

The library is called Moo. I like the sound. And if at some point the library supports multi-objective optimization too (not yet), the name will sound even better.

Some links:

Current feature set:

  • binary GAs with binary and Gray encodings
    • point mutation
    • one-point, two-point and uniform crossover
  • continuous (real-valued) GAs
    • gaussian mutation
    • BLX-α, UNDX and SBX crossover + same as in binary
  • selection operators
    • tournament
    • roulette
    • optional elitism
    • optional fitness scaling
  • constant-space strict iteration routines
    • optional digest (sort of logging)
    • simple and compound stop conditions

Things to do before the first "real-world" release:

  • a test suite (any suggestion for testing non-deterministic algorithms?)
  • support for permutation algorithms
  • GensNoChange as a stop condition
  • (maybe) support for at least one multi-objective optimization algorithm
  • (maybe) support for time-dependent mutation
  • (maybe) support for steady-state algorithms
  • cleanup iteration routines, allow IO interleaving
  • more examples (there are some; at least one for every major GA variety; more classical problems)

As you see I'd like to cover as diverse algorithms as possible in the first release. My motivation is to streamline the API and make sure it adapts to different kinds of genetic algorithms. More mutation, crossover and selection operators will be easier to add later. The purpose is to make the library a tool to solve optimization problems even by a person who is not expert in GAs.

So far it is a good exercise in designing APIs. There are many kinds of GAs possible, everyone creates his own, and what makes the GA library an interesting task is to allow to combine different building blocks together. I can explain some design solutions in my blog if anyone is interested.