1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
|
- Development Branch -
29/1
Started formal development based on data_struct spike.
The first goal is to produce the data structure that represents a chromosome. This structure will rely on a range
of other classes, which will be developed and tested as well.
Chromosome tests:
- a data structure called Chromosome exists
- the chromosome instance can return the right outputs based on given inputs
ChromosomeElement tests:
- Node is capable of processing its connections using its function and returning the result
- Input returns the value it is set to
- Outputs returns a single value from its source Node
30/1
Added class representations of functions and mutators, as well as the program itself (CGP).
Modified the way the chromosome stores its data to allow for more flexible mutations.
31/1
Parity will be considered constant, at 2, for now.
Added static nested classes for system-wide resources such as a random number generator, the function set
and the parameter set. These can be accessed from anywhere within the program, but not modified by any class
but CGP.
Utilities class has lots of handy methods for getting random elements with fair probability.
Modularized design:
Modules for fitness function, mutation operator, evolutionary algorithm and population.
FF, EA and mutation modules act as callbacks; the user may specify how the module does its job,
but must comply with the interface.
Population is slightly more complex: the user may define a custom chromosome and use it to generate a population,
so long as it extends Chromosome. In conjunction with modularized FF, EA and mutation, this makes for a very
flexible and versatile system. The Population class itself is immutable, since the system relies heavily on it.
Finally, it is Iterable to for access to the chromosomes within.
Arity may vary across functions, but all nodes contain enough connections to cope with the largest arity.
FunctionSet presents a bit of a problem in case the user retains references to the Functions passed into it.
3/2
Solved the FunctionSet problem; since Function does not specify a way to modify the function once it is instantiated,
concurrent accesses should not be a problem. Should the user extend Function and implement a way to modify it at
runtime, the CGP program won't really use it; if the user modifies the CGP program to use it, then the user must
be ready to deal with the consequences.
A fitness evaluation testbench of sorts will be implemented next. This testbench will take a set of "stimuli" (inputs),
use them to compute outputs with each chromosome, and compare those with the expected outputs, thus assigning fitness.
This will be achieved for now using a TestCase object which contains a set of inputs and outputs. The evaluator simply
sets the chromosome inputs and compares outputs for all TestCase objects given, and computes a fitness function
accordingly.
4/2
TestCase has been implemented with a fair degree of defensiveness. A TruthTable class contains the test cases and provides
a way to evaluate fitness.
TruthTable is a system-wide resource, which may or may not be used by FitnessFunction to assign fitness values to the
population; that is up to the user.
A standard fitness function which uses TruthTable is defined in TruthTableEvaluator.
StandardMutator has been implemented, though it looks like it may need refactoring in the future.
StandardEA presents a problem: mutating the highest fitness chromosome to generate a new population requires the
chromosome to be copied, which is not straightforward in OOP. This could be addressed by creating a shallow copy
and instantiating new Nodes during the mutation process. This is actually an implementation of a lazy copy which
takes advantage of common Nodes to save memory. Additionally, this will require the mutation to actually occur within
the chromosome and simply be triggered from the Mutator. This reduces the number of Utilities functions, which is not
necessarily a problem.
7/2
The resource classes have been refactored so that tests can be implemented more easily. Parameters, Utilities and TruthTable
are now top-level classes and work independently from CGP, allowing them to be initialised for testing purposes. Some
chromosome tests have been written and more tests will be written in the next few days.
11/2
Methods to get random connections and mutable elements have been moved into Chromosome, as well as refactored to require
less random number generations.
Chromosome and its associated members (Node, Output, Input) have been refactored to allow copying. A copy constructor has been
written which initialises a new chromosome as an exact copy of a given chromosome.
Cloning has been tested and is working.
Active node detection will be implemented via a getActiveNodes() method in Chromosome. The chromosome is notified whenever
one of its nodes or outputs is mutated, and re-computes the list of active elements when it is required. It does so by recursively
acquiring node connections and copying them to a separate list, unless they are already on the list.
All chromosome tests have been implemented.
12/2
Node tests done. Added exception support for Function in case not enough argument connections are given.
Chromosome tests refactored to include the special case where columns = 1.
Input and output tests written.
|
