Tutorial

Tutorial (v 0.5.0)

A brief tutorial on how to use the evolver.

• Tutorial (v 0.5.0)
  • Generate configuration
  • Modify the configuration template
  • Settings template
  • <UI>
    • <DisplayNegativeValues>
    • <GenerationFolder>
    • <GenerationType>
    • <ArchiveFolder>
    • <ArchiveType>
  • <genetic>
    • <PopulationSize>
    • <Generation>
    • <Warriors>
    • <MinCycles>
    • <Comment>
    • <FitnessFunction>
    • <Crossover>
    • <Mutation>
      • <OpCode>
      • <Modifier>
      • <Mode>
      • <Address>
  • Final test.xml example
  • Running the evolver

Generate configuration

The genetic algorithm needs to have a configuration. You can have multiple GA projects, each one with its own configuration. The GA configuration is written in a XML file, and as a first step you can instruct the evolver to generate a configuration template for you.

To generate the initial configuration template, you run the following command:

> java -jar CWEvolver-0.5.0.jar -GC test.xml
Java GA Redcode evolver v 0.5.0
Copyright (c) 2005-2014, Miha Vitorovic

This generates a XML configuration template named test.xml in the you specified location.

Modify the configuration template

Opening the file reveals three sections:

• <mars>
• <ui>
• <genetic>

Section mars contains the standard MARS parameters. You can tweak these to your own liking.

Settings template

Opening the file "test.xml" shows:

<GAEvolver xmlns="http://sourceforge.net/projects/cw-evolver/">
   <mars>
      <CoreSize>8000</CoreSize>
      <MaxProcesses>8000</MaxProcesses>
      <MaxCycles>80000</MaxCycles>
      <MaxLength>100</MaxLength>
      <MinDistance>100</MinDistance>
      <Rounds>1</Rounds>
      <PSpaceSize>500</PSpaceSize>
      <ReadLimit>8000</ReadLimit>
      <WriteLimit>8000</WriteLimit>
   </mars>
   <ui>
      <DisplayNegativeValues>0.75</DisplayNegativeValues>
      <GenerationFolder>C:\cw-evolver</GenerationFolder>
      <GenerationType>FOLDER</GenerationType>
      <ArchiveFolder>C:\cw-evolver</ArchiveFolder>
      <ArchiveType>FOLDER</ArchiveType>
   </ui>
   <genetic>
      <PopulationSize>0</PopulationSize>
      <Generation>0</Generation>
      <Warriors/>
      <MinCycles>50</MinCycles>
      <FitnessFunction>1</FitnessFunction>
      <Crossover rate="0.5"/>
      <Mutation probability="0.01"/>
   </genetic>
</GAEvolver>

<UI>

UI section basically sets the location of the configuration, how the configuration is packed, how and where the generations are archived and how to display addresses, where it applies.

<DisplayNegativeValues>

As you know MARS only works with positive values, but when viewing sources, it is helpful to see some offsets as negative values. The value of this setting is a double number between 0.0 and 1.0. The default is 0.75, which basically means that all offsets larger than 75% of the core size will be displayed as positive numbers, while larger ones will be displayed as negative numbers.

For example, for a core size 8000 affsets 0-6000 will be displayed as positive numbers, and offsets 6001-7999 will be displayed as negative numbers - 7999 meaning -1, 7998 meaning -2, etc.

<GenerationFolder>

Contains a folder where the evolver can expect to find the warriors for the current generation, or the ZIP file, depending on the generation type.

<GenerationType>

Specifies the type of the generation. Possible values are FOLDER or ZIP. The default value is the folder in which the generation was generated.

I suggest this option is changed to ZIP.

<ArchiveFolder>

Specifies the folder into which the evolver will generate the archive of each generation, along with the report of the battles and the genetic operators.

<ArchiveType>

Specifies the type of the archive. Possible values are FOLDER, ZIP or NONE. The default value is the folder in which the generation was generated.

I suggest this option is changed to ZIP.

<genetic>

If there are any warriors in the folder where you run the -GC command the evolver includes them into the generated XML file.

<PopulationSize>

Adjust this to your desired generation size. This is either 0 or equals the number of warriors in the folder when the configuration was created. For example we set this number to 100. This means, that the application will generate 100 random warriors.

<Generation>

This parameter is managed by the application and should be left unchanged.

<Warriors>

This parameter is managed by the application and should be left unchanged.

If the folder contained any warrior files and they are listed here, you may remove some. If the list contains less warriors than stated in the <PopulationSize> parameter the application will randomly generate additional warriors.

<MinCycles>

This parameter is intended for lower generations if all the warriors are randomly generated. This ensures that the application tries to run each warrior for at least this many cycles.

In normal circumstances the application will run the battle until one of the warriors stops. This makes the other warriors automatically a winner. With randomly generated warriors it would make little sense to declare a winner, if one warrior stops after one instruction, and the other one would stop after three instructions. This setting makes sure that the second warrior is left to run for at least 50 cycles even if the first one already stopped. With this the application should detect false winners.

Since the maximum size of the warrior is 100 instructions I suggest setting this parameter to 150.

<Comment>

Before the <FitnessFunction> there is an optional parameter which allows you to put in any text. The intended use is to provide a description of the fitness function formula, which can become pretty lengthy and complex. Especially after you have not looked at it for a while.

<FitnessFunction>

A function which evaluates each warrior after a battle. The bigger the value, the more successful the warrior is. Please note that the idea of the fitness function is not to write it once and then never change it again. The fitness function can be tweaked as the generations progress to calculate the success of the warrior with the most accuracy. I also plan to add additional variables in later versions to enable better warrior analysis.

Let's try this formula for start (from the [Readme]):

((cycles<=1)*(-500)+((cycles*1.0/size)<0.1)*(-100)+(((cycles*1.0/size)>=0.1)&&((cycles*1.0/size)<0.4))*100+(((cycles*1.0/size)>=0.4)&&((cycles*1.0/size)<1.0))*300+((cycles*1.0/size)>1.0)*1000)*(!((cycles>size)&&(maxEI>0.4)))+((cycles>size)&&(maxEI>0.4))*(-500)

What does it mean? It is all the expressions from the [Readme] added together (as suggested there), and then multiplied by "!((cycles>size)&&(maxEI>0.4))". This expression will evaluate to "1" if the warrior didn't stall. This in turn will evaluate the entire expression to the actual fitness of the warrior. If the warrior did stall, this will evaluate to "0" and this first part of the expression will be ignored.

• (cycles>size) means that the warrior ran for longer than its length
• (maxEI>0.4) means that is executed a single instruction for more than 40% of that time. This is a pretty good indication that the warrior stalled.

The second part of the expression "((cycles>size)&&(maxEI>0.4))*(-500)" will evaluate to "-500" if the warrior did stall.

<Crossover>

The <Crossover> tag has one attribute rate. This is a number between 0 and 1, and it specifies the percentage of warriors that is replaced with offspring warriors created by crossover operations.

The <Crossover> section contains one or multiple <Operation> tags. Each operation tag has an optional ratio attribute, which is again a number between 0 and 1. If the attribute is omitted, the default ratio is 1/n, where n is a number of the crossover operations.

The sum of all operation ratios does not need to be 1. For 3 operations ratios of 0.25, 0.25 and 0.33 actually correspond to ratio 3:3:4 respectively. The ratio in this case specifies how probable it is that the operation will be selected for the crossover.

The actual operation is a string of letters a and b which represents how the two warriors are mixed together. Warrior a is always the one with the higher fitness score.

Example:

   <Operation ratio="0.4">aab</Operation>

The warrior produced by this crossover operation starts with the first 2/3 lines of warrior a and the last 1/3 lines of warrior b.

<Mutation>

The last part of the <genetic> section is the <Mutation> section. It has the probability with which each line in each warrior produced by crossover is mutated. The default probability is 0.01.

It has 4 possible mutation operations:

• <OpCode>
• <Modifier>
• <Mode>
• <Address>

<OpCode>

<OpCode> has two optional attributes: ratio and value. The value for ratio is a number between 0 and 1, and the value can be any of the opcodes or rnd (opcode is selected randomly). The default values for the two attributes are 1/n and rnd respectively.

<Modifier>

<Modifier> has two optional attributes: ratio and value. The value for ratio is a number between 0 and 1, and the value can be any of the opcode modifiers or rnd (modifier is selected randomly). The default values for the two attributes are 1/n and rnd respectively.

<Mode>

<Mode> specifies the addressing mode and has three optional attributes: ratio, position and value. The value for ratio is a number between 0 and 1, the value for position can be a, b or rnd (position is selected randomly), and the value can be any of the modes or rnd (mode is selected randomly). The default values for the three attributes are 1/n, rnd and rnd respectively.

Note: because of the restrictions of the XML, the two modes < and > have been replaced by B_PRE and B_POST respectively.

<Address>

<Address> specifies the address and has three optional attributes: ratio, position and value. The value for ratio is a number between 0 and 1, the value for position can be a, b or rnd (position is selected randomly), and the value can be any number in the range -999999..+999999 or rnd (address is selected randomly). The default values for the three attributes are 1/n, rnd and rnd respectively.

Final test.xml example

In the end the test.xml file could look similar to this:

<GAEvolver xmlns="http://sourceforge.net/projects/cw-evolver/">
   <mars>
      <CoreSize>8000</CoreSize>
      <MaxProcesses>8000</MaxProcesses>
      <MaxCycles>80000</MaxCycles>
      <MaxLength>100</MaxLength>
      <MinDistance>100</MinDistance>
      <Rounds>1</Rounds>
      <PSpaceSize>500</PSpaceSize>
      <ReadLimit>8000</ReadLimit>
      <WriteLimit>8000</WriteLimit>
   </mars>
   <ui>
      <DisplayNegativeValues>0.75</DisplayNegativeValues>
      <GenerationFolder>C:\cw-evolver</GenerationFolder>
      <GenerationType>ZIP</GenerationType>
      <ArchiveFolder>C:\cw-evolver</ArchiveFolder>
      <ArchiveType>ZIP</ArchiveType>
   </ui>
   <genetic>
      <PopulationSize>100</PopulationSize>
      <Generation>0</Generation>
      <Warriors/>
      <MinCycles>150</MinCycles>
      <FitnessFunction><![CDATA[((cycles<=1)*(-500)+((cycles*1.0/size)<0.1)*(-100)+(((cycles*1.0/size)>=0.1)&&((cycles*1.0/size)<0.4))*100+(((cycles*1.0/size)>=0.4)&&((cycles*1.0/size)<1.0))*300+((cycles*1.0/size)>1.0)*1000)*(!((cycles>size)&&(maxEI>0.4)))+((cycles>size)&&(maxEI>0.4))*(-500)]]></FitnessFunction>
      <Crossover rate="0.25">
         <Operation>ab</Operation>
         <Operation>aab</Operation>
         <Operation>ba</Operation>
         <Operation>baa</Operation>
         <Operation>abba</Operation>
         <Operation>baab</Operation>
      </Crossover>
      <Mutation probability="0.01">
         <OpCode/>
         <Modifier/>
         <Mode/>
         <Address/>
      </Mutation>
   </genetic>
</GAEvolver>

Running the evolver

Now you can try running the evolver with the command

java -jar CWEvolver-0.5.0.jar -RC test.xml

Work in progress.