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
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
|
- 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.
Population tests under way.
13/2
Writing the test for the population copy constructor will require the production of a method which compares two chromosomes.
Therefore, two new methods will be written for Chromosome: compareTo and compareActiveTo. Compare returns true if the two chromosomes
are exclusively equivalent, and compareActive returns true if the active nodes within the two chromosomes are exclusively equivalent.
Compare methods done, including their "dependency": copyOf method in MutableElement. This method is akin to equals(), with the exception that
it returns false when the compared objects are pointers to a common instance.
Minor update: Node now passes only the necessary number of arguments into its function; this allows the node to compute its active
connections as it knows which connections the function will use (based on arity).
14/2
Support for generic data types implemented.
Tests have been refactored to deal with the new data system. The system uses Object as its data type, allowing absolutely
any class to be used (and also primitive types).
15/2
The Population class will be refactored to contain two collections of chromosomes, one for parents and one for offpsring. This allows
for (1+λ) and (1,λ) EAs, for example. It no longer makes sense for Population to implement Iterable, so the tests will be changed to reflect
the specification change. Population can still return an addressed chromosome in general, which it does by returning parents followed by offspring.
The chromosome copyConnections method has been made public to facilitate the EA implementation.
16/2
Methods were added to Chromosome and Connection to allow the chromosome to be printed to the console. This way its behaviour can be verified to make
sure the fitness evaluations are working correctly and any perfect solution found really is producing perfect outputs.
A test case has been calculated by hand from the printed chromosome, and indeed the system appears to be working.
However, if the implemented run() in Function subclasses is set to print the operation it has carried out, the first function execution of each output
prints twice -> because it needs to check what it is to cast it. Very inefficient...
Instead, we'll attempt to cast it without checking, and a ClassCastException will be raised if a problem happens, telling the user they did something wrong.
This can be caught by the GUI to display an error message, if necessary.
Added a new parameter, debug. When set to true, the system prints a lot of information to the console for debugging purposes.
Added some more functions.
8/3
Adding GUI package, refactoring CGP class to interact appropriately with GUI.
15/3
Currently refactoring Parameters. It is now a part of CGP.class as stated in the phase report. The rest of the program will now be refactored to accommodate these changes. Inversion of
will be employed to avoid static accesses to CGP, and the tests will be modified accordingly. This will allow multiple instances of CGP to co-exist.
18/3
The current state of parameters is not yet perfect. One more refactoring will be carried out to speed up GUI updates.
Modules will be required to return a hashmap of parameters so the GUI can be re-built easily whenever modules change.
Modules should instantiate their parameters in their constructor and use direct referencing internally for extra speed.
The hashmap may be pre-built to save time when getParameters() is called, though this is not critical.
19/3
Refactoring is complete, population tests have been refactored as well. It is worth noting that the new resources
framework leads to a lot of confusing casting. Utility methods will be written to hide away the casting in the CGP
class and simplify the programmer's life.
Registering parameters is no longer necessary. The CGP class will query modules for their parameters when necessary.
21/3
FunctionSet has been rewritten to allow only certain functions to be deactivated, the GUI will now be integrated.
|
