An instance of an IProgram
subclass represents a single individual in a population of individuals which are evolving against some problem. Consequently this is a central class and along with the IPopulation
subclass it contains most of the functionality of an instance of VUWLGP. Primarily this class is responsible for:
IProgram
, e.g. MultiClassProgram
.
The constructor of a program has two responsibilities. It should pass a pointer to a fitness measure to the IProgram
constructor, and this memory will then be managed by its destructor. It should also create each of the instructions, ideally using its InstructionFactory
method, for consistencies sake as this method is what is used elsewhere. The subclass will also need to implement a deep destructor and copy constructor.
This method should be abstract but unfortunately that isn't possible in C++ (yey for a broken and rather decrepit object model), hence the basic implementation in IProgram
throws an exception. All that the reimplementation of this function needs to do is return a pointer to a new instruction, using whichever instruction class this class of program should use. The memory for these instructions is then managed and deleted in IProgram::~IProgram
.
This method does not need to be reimplemented in any subclass - it is only mentioned here because it so blatantly violates object encapsulation. Thus, an explanation.
Evolutionary operations are members (and would ideally be mixins and so just friends) of IPopulation
and its subclasses. This is because they need internal access to the private members of populations so that the resulting programs they create can replace existing ones.
IProgram
and its subclasses - else how would they change part of a program? Each such function could be made a friend, but since friendship isn't inherited this would be clunky and frustrating to use. Hence this function, which at least has a clunky and blatantly evil name. It should only be necessary to use this method and it's const partner ConstRawAccessToTheInternalInstructions
in evolutionary operations.
Christopher Fogelberg
fogelbchri@mcs.vuw.ac.nz or cgf.unimail@syntilect.com