Re: Genetic Algorithms in Swarm

[Paul Johnson]

>         The distributed SwarmModel of GM is based on the individual approach 
> of genetic algorithm, i. e. each individual of the GA is like an agent, but 
> the kernel of GM is able to act as well following a mind-approach, i. e. the 
> individuals of the GA are like ideas into the brain of a single agent and 
> each agent have an own population. Because the kernel is able to operate on 
> several population, in fact each agent can have an own GA.This approach is 
> followed in CW for classifier systems. For more information please mail me.
> 
>         About developing GM and CW I'll send as soon as possible a new 
> version of them with few additional features. I know the problems arising 
> from using software under modification and I promise to take care in preserve 
> compatibility with old versions.
> 
Thanks very much for sharing GM with us. I'm getting a much better idea
what is involved in using GA.  My purpose, I think I mentioned, is to
revise the ASM code in the BFAgent class (ArtStkMkt.sourceforge.net).  I
have run up against a couple of problems.

First, in the ASM, they are true to the Holland notion that the "bits"
can have 3 values, "1" "0" and "#", which means "don't care" or "not
specified".  I don't see in the info on GM how you are dealing with that
issue. 

Second, I am following the path you describe where each individual agent
has a population of possible approaches to the problem.   In ASM, the
BFAgent has strings that have both "bit" values and "real" values, like
this (0,1,0,1,# | 9.3, 4.1, 6.3). The vertical bar separates the two
kinds of values.  The real values, as far as I understand it, do not
allow the # value, a number must be specified. The BFAgent evolves the
real values during the process of evolving the bit values. 

Do you have any intention of putting an ability to handle real values
into GM?

While this is fresh on my mind, could I suggest something for your
documentation: it would be useful to me (and others?) if you said
something like this:

How to use the RuleMaker class in applications.  The files RuleMaker.h &
RuleMaker.m can be included directly in your program directory.  It is
also necessary to include the files Macro.h and Trace.h, which provide
some short-cuts and debugging output control.  It is necessary to
include Embryo.h & Embryo.m.  Embryo does not generally need to be
edited by the user.  Embryo is a support class "Embryo" that supplies
objects that can hold genetic information new "configurations" (?) are
created.  It is necessary to also include the Interface.h & Interface.m
files.  The Interface class is the information-container that keeps data
on the genetic string and its fitness level.  All of these must be added
to your Makefile in the appropriate way.

The RuleMaker object can take genetic and fitness information from
instances of the Interface class.  The user can create as many instances
of the Interface class as desired, one for each possible genetic
string.  In the standard RuleMaker usage, a Swarm list of these
instances should be created, and the RuleMaker is told to
setPopulationList to that list. Later, when the RuleMaker is told to
"evolve" that list, it can grab whatever information it needs from each
instance in that list.  The contents of the interface list (which is
called the populationList inside RuleMaker) can change during the course
of a simulation, of course, either as a result of changes caused by
RuleMaker or in other parts of the program.  

The user has the option of writing his own class, called Agent in this
code example, and keeping the interface objects inside that class.  When
the populationList is set in the RuleMaker, a Swarm list of these Agents
should be passed in.  There is a declaration in the Macro.h file that
can be used to tell the RuleMaker that the list refers to Agents, not
"naked" interface objects.  The Agent class that the user creates must
respond to the message "getInterface" which is used by RuleMaker when it
makes its calculations.  (my personal opinion is that you should specify
a protocol and then have the Agent adopt that, just to make it clear). 

Incidentally, I think there is a better way to deal with the AGENT
selection than the macro. Probably it would be better to have a method
in RuleMaker like

-isAgent: (BOOL) value

and then put some if-then statements to make the right things happen.  I
think in the ideal situation, you would not want the users editing your
core files at all, and they should interact through your interface,
rather than by editing in your files.  Another possibility would be to
use a C preprocessor flag.  

-- 
Paul E. Johnson                       email: address@hidden
Dept. of Political Science            http://lark.cc.ukans.edu/~pauljohn
University of Kansas                  Office: (785) 864-9086
Lawrence, Kansas 66045                FAX: (785) 864-5700

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.