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
|
- 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.
|
