In this tutorial, we look into a new approach to coding Genetic Algorithms in an object oriented language. Most libraries available let the GA take control of the application. We show how this is ill-suited to complex world simulations, with multiple agents based on evolution.

We propose a new solution, based on the client-server paradigm, which is more convenient for online-evolution as well as parallel implementations. Finally, the affects such a learning approach within the game are discussed.

http://geneticalgorithms.ai-depot.com/Tutorial/GAclass-Motivation.html

Look at the lovely code formatting ;) That was fun!

By some strange coincidence I designed a GA system like this 2 weeks back. While the code currently isnt fit for publishing, possible soon, I will share my approach.

When I sat down to create this I decided I wanted the to be able to mix and match GA engines and Individuals as much as possible.

My approach is slighty different from yours in that I decided that the engine should handle the logic/algorithm of crossover and mutation, since this can be done in many different ways, and the indiviual should provide the means a means of manipulating itself in true OOP style.

I also wanted the core GA Engine code to be implemented once, and custoimized crossover and mutation should be altereable without effecting the core code.

My last decision invovled statistics, I decided to implement a few stats as standard, Min, Max & Avg Fitness, so these are part of the base classes and expected.

What I came up with is the following:

There are 3 base classes:

TIndvidual
TPopulation
TGAEngine

The Indidvidual Base class is completly Abstract, but I did implement a standard dynamic array version of it. The basic idea is that I assume that every individual will have sequential indexed access to whatever it represents. The index could represent anything you wanted for the specific problem. Could be limiting in some situations, but suffient for most purposes.

Individual supports the following virtual methods:
-Create(Randomise: boolean)
-Destroy
-CreateSpawn(Randomise: boolean): TBaseIndiviual;
This method is used to make my individuals self replicating, so the typical code looks as follows for a class called "TCustomIndividual":
Result := TCustomIndividual.create(Randomise);
-Randomise
Just like the name says, populates the indivual randomly.
-CopyFrom(FromIndv: TBaseIndv; FromStart, FromEnd, ToStart, ToEnd: longint)
This method allows the GA engine to perform cross over in any fashion it likes, while leaving the implementation details to the Indvidual. The method should copy the speicied index range from the supplied Indv into itself at the specified positions.
It should handle size mismatches etc, which is easy to implement.
-Mutate(Index: longint)
This function allows the GA Engine to control Mutation, and mearly tells the Indv which indexed position to mutate. How it is mutated and what the index represents is complety up to the Indv.
-CalculateFitness
This method is called to update the public field Fitness of the base class which is used by the GA Engine. I didn’t see the need to impose translation methods as if needed they can be added in to any custom classes made, but this function will be called to resolve the fitness.

The structure of the Population and Engine Class is not really relevant except to say that Cross over and mutation are each housed in virtual methods of the GA Engine, and can overriden in descendant classes without effecting the core GA.

The basics of the engine are simple, To start it you must pass it an instanced object of the indvidual you want to use. It will use this Indv to spawn the population using the method SpawnCreate above. It mearly tops the population up to the population size so it is very easy to pre load some indv’s before starting the GA.

So far this is worked very well, and the performance has been resonable.

I would be interested to see how your generic class system compares with mine.

Cheers

Alex,

I've been thinking about your class design for a couple of days. Have you considered whether the server could be implemented as a wrapper around a more conventional implementation? It would thereby act as a proxy; caching individuals created by the GA until requested by the fitness function as a candidate. Are there any aspects of the class design that would prevent this in principle? I ask because it would be better to be able to cater for your approach while supporting the more traditional and familiar models as well.

-RoB-

Well, we must be on the same wave length... my implementation could be classed as 'conventional', and this wrapper does exactly that. That said, my algorithm has been chosen to match and make the implementation easier (i.e. it's incremental as opposed to steady state). My candidate cache is 1 (caching the daughter offspring and returning the son immediately), but with a cache of N you could implement a steady state GA without any trouble.

This new approach was intended to be more convenient for OO game design, not necessarily requiring a different GA implementation. I should have emphasized that a bit more.

My concern was precisely that there might be problems wrapping a Steady State GA that I hadn't spotted. So, in theory, a similar wrapper could be added to GALib so that those unfortunate enough not have have their own GA library can experiment with this approach? :-)

I'll look at adding the wrapper to my GA library. It's written in Java and already makes good use of generic classes so it should be a pretty easy extension to add to the evolutionary core.

It looks like a convenient way to support "interactive evolution"; my particular area of interest. For this the wrapper will have to handle multiple individuals being evaluated at once -- but that's not really any different to your requirements.

I'll let you know how I get on...

-RoB-