The original GAlib implementation evolved over the course of 3 years. I started GAlib after using a GA library written by Kazu Saito at the MIT CADlab. As my first major C++ programming effort, GAlib started out as a programming exercise. Eventually I found that I needed a full-featured, extensible, and reasonably fast genetic algorithm package for my doctoral work. Since there was nothing available at the time (circa 1993) I decided to make GAlib do the job. Others in the CADlab and various optimization courses at MIT found it useful, so I ended up making it even more extensible and cross-platform-happy. GAlib made its first public appearance in the spring of 1995.

My doctoral work was largely funded by the Leaders for Manufacturing Program.

As of 1999, I am maintaining GAlib in a fairly feature-complete state. I continue to add minor features, fix bugs, and tweak for new platforms and compilers. Thread safety is high on the list of additional features to be added.

Yes. As of Fall 1999, GAlib is free for any use, commercial or otherwise. The only stipulation is that the copyright notice be included in any derivative works. The licensing of GAlib is now similar to that of the XWindows software, but not as restrictive (from a commercial point of view) as the GNU public license.

There are two GAlib mailing lists, one for announcements and the other for general questions.

The general GAlib mailing list is galib at mit.edu. This is an unmoderated list for questions about GAlib and how to use it. Please read the GAlib documentation before you send your questions to this list. To subscribe or unsubscribe, go to http://mailman.mit.edu/mailman/listinfo/galib

The GAlib announcement mailing list is galib-announce at mit.edu. This list is used by the author of GAlib to announce new releases of GAlib. Traffic on this list is typically two or three messages per year. To subscribe or unsubscribe, go to http://mailman.mit.edu/mailman/listinfo/galib-announce

The GAlib mailing list is archived at http://mailman.mit.edu/pipermail/galib

There is currently no newsgroup for galib. However, the comp.ai.genetic newsgroup is a good place to go for help with genetic algorithms in general and often with specific problems as well.

GAlib was designed to make it easy to try different objective functions, representations, genetic operators, and genetic algorithms. It includes many different representations, genetic operators, genetic algorithms, stopping criteria, scaling methods, selection methods, and evaluation schemes. For a complete list of features, see the feature list.

GAlib will compile under Visual C++, but Microsoft's compiler is overly strict about types without being smart. It adheres so strictly to the ANSI standard that it becomes a real pain in the #@$! to use.

In GAlib 2.4.x you will have to add explicit casts to many member functions to get the library to compile. For example, instead of simply saying

        GARealGenome mygenome(10);
        float x = mygenome[5];

you must do it this way:

        GARealGenome mygenome(10);
        float x = mygenome[(unsigned int)5];

The compiler also warns about statements such as float x = 0.0; You can disable these warnings by inserting these lines into gaconfig.h:

       #if defined(_MSC_VER)
       #pragma warning (disable : 4244)
       #pragma warning (disable : 4305)
       #endif
       

You must tell GAlib to not use the streams library (by default it is configured to assume a command-line environment, including streams). To turn off streams, edit the configuration file gaconfig.h and define the NO_STREAMS macro. Or define the macro NO_STREAMS in your project settings. (It is safer to define the macro in the header file so that you do not forget to set it in subsequent projects that use the GAlib headers.)

You may have to force VCPP to ignore the LIBCD library using the ignore libraries option in your project settings on the link properties panel.

GAlib 2.4.5 requires only slight modification in order to build properly with gcc 3. You may have to make the following modifications:

in the file ga/GAAllele.h, change this:

#elif defined(__GNUG__)
  friend int operator==<T>(const GAAlleleSet<T> &, const GAAlleleSet<T> &);
  friend int operator!=<T>(const GAAlleleSet<T> &, const GAAlleleSet<T> &);
#else

to this:

#elif defined(__GNUG__)
  friend int operator==(const GAAlleleSet<T> &, const GAAlleleSet<T> &);
  friend int operator!=(const GAAlleleSet<T> &, const GAAlleleSet<T> &);
#else

I am not yet certain of the versions of gcc 3 where these changes must be made. When I build on MacOSX 10.3 I have not had to make any modifications, but when I build on a fairly recent release of Red Hat linux, I have had to make the changes. One of these days I'll sort out exactly which gcc version requires the modifications, or better yet I'll do a release of GAlib that compiles properly with each of them, without requiring changes.

This usually applies when using gcc 3 or another modern compiler.

GARealGenome.h defines some inline functions that are also defined in GARealGenome.C. To keep the compiler happy, all definitions must be done before instantiation, so moving the definitions of

float GAAlleleSet::allele() const
float GAAlleleSet::allele(unsigned int i) const

to be before any of the inline functions in GARealGenome.h will solve the compile problem.

Thanks to Bertrand Mesot for pointing this out.

There is an extensive overview included in the GAlib documentation. It explains the basics of genetic algorithms as well as the design philosophy behind the GAlib implementation. The distribution includes many examples that illustrate the use of GAlib, and the documentation includes examples of how to derive your own classes.

In general, start with an example that is similar to your problem, then go from there. We have found that people struggle with the following issues: (1) learning C++ and object-oriented design in general; (2) how to represent the problem; (3) how to define then refine an objective function that will actually do what you want it to do; and (4) how to handle multiple, and often conflicting, objectives. Please read the overview!

Nine times out of ten, a real number genome will perform better than a binary string genome. However, actual performance depends on the problem you are trying to solve. If you use a binary genome to encode real values, then chances are the real number genome will do better.

Remember also that the genetic operators are closely coupled to the representation. It is possible to choose the 'right' representation but the 'wrong' genetic operator, or vice versa.

This depends on the problem you are trying to solve. For any given problem, there are many different representations you could use. Of those representations, some may work much better than others. As you experiment with different representations, remember that the genetic operators and your evaluation function affect performance at least as much as the representation. And they are usually all closely coupled.

As you work on a new problem, start with something simple. Make simplifying assumptions if needed, but get something that works. Then you will have something to use as a benchmark for evaluating the performance of other representations and operators. If you manage your code properly, you can mix and match operators, representations, and objective functions so that you can evaluate the performance of each component.