EC3:  A More Flexible Evolutionary Computation System

The Java code in this directory is a generalization of the EC2 code as
discussed in Chapter 4, namely, parameterizing the choices for each of
the basic EA components to allow tinkering with the components of the
canonical EAs, and to be able to assemble entirely new EAs by mixing
and matching the basic components.

In keeping with the KISS philosophy of EC1 and EC2, EC3 is also
implemented as a "command line" system rather than a GUI, and uses
a configuration file paradigm to specify user-selectable options to
EC3.  In particular, a configuration file can now contain:
	EA=xx
where xx can be one of:  EV, EP, ES, GA or UN, allowing a user to
choose which EA to apply to a particular problem.  If no EA=xx
is present, the system defaults to UN (unspecified).  Whenever
the EA is UN, all the basic components must be specified.  For
the other EA types, the basic components can be specified but
standard defaults are provided.  The required components are:

1. A parent selection method specified as ParentSelection=xxx
where xxx can be:  
	uniform_stochastic	(EV default)
	uniform_deterministic	(EP and ES defaults)
	fitness_proportional	(GA default)
	binary_tournament


2. An indication of the type of generational model to be used
specified as GenerationType=xxx where xxx can be:
	overlapping	(EV, EP, and ES defaults)
	nonoverlapping	(GA default)


3. A survival selection method specified as SurvivalSelection=xxx
where the values that xxx can be depend on the GenerationType.
For overlapping generations xxx can be:
	truncation		(EP and ES defaults)
	binary_tournament	(EV default)

For nonoverlapping generations with offspring population sizes
larger that their parent population size, xxx can be:
	truncation	  (ES default)
	binary_tournament
	fitness_proportional
	uniform_stochastic


4. A representation type specified as Representation=xxx where xxx
can be:
	real 	(EV, EP, and ES defaults)
	binary	(GA default)


The specification for reproductive operators is now expanded to:

	Mutation=<type> <freq> <step> <adapt>

where <type> can be:  none, delta, or gaussian	(real representations)
		      none or bitflip		(binary representations)

where <freq> can be:  one	(mutate one gene on average)
		      all	(mutate all genes on average)

where <step> is the real-valued step size for delta and gaussian mutation,

and where <adapt> is the real-valued mutation adaptation parameter.



Crossover is currently representation independent and specified via:

	Crossover=<type> <freq>

where <type> can be: none, one_point, two_point or uniform

and <freq> is the real-valued parameter for uniform crossover.



So, an EC3 configuration file might be:

  EA=ES
  PopSize=1 10
  Representation=real
  Mutation=gaussian all 1.0 0.1
  GenerationType=nonoverlapping
  Landscape=RVP Parabola 2 -4.0 6.0 hard
  SimLimit=1000
  RandSeed=12345
  Report=full

which represents a fairly traditional (1,5)-ES with a real-valued
representation and Gaussian mutation.


Alternately, a rather unconventional EA can be specified as:

  EA=UN
  PopSize=20 3
  ParentSelection=uniform_deterministic
  GenerationType=overlapping
  SurvivalSelection=binary_tournament
  Representation=binary
  Mutation=bitflip
  Crossover=uniform 0.2
  Landscape=RVP Parabola 2 -4.0 6.0 hard
  SimLimit=1000
  RandSeed=12345
  Report=bsf

 
For simplicity in Chapter 4 and in the EC3 code, there is still only
one class of problems (fitness landscapes), namely, real-valued
parameter optimization problems.  The will be generalized in EC4.

As with EC1 and EC2 the complete details are best understood by
reading the EC3 code, which is what you are expected to do!  The major
differences between EC2 and EC3 are to be found in the EA class
extensions.





