• No results found

2.6 Algorithm coding

2.6.1 Testing of the algorithm

To first test the ability of the algorithm to obtain solutions, individuals con- sisting of 50 elements having the range 0–99 were used. The requested solu- tion was a simple one: The sum of all the elements in the individual should be zero. A population size of 100 with 10% offspring was used (i.e. 10 offspring per generation) and the threshold (the fitness at which the algorithm stops seeking) set to zero, i.e. a perfect solution. When run with these parameters the GA found the ideal solution in 9740 generations. A plot showing the evo- lution of the algorithm is shown in Figure 2.19. What is seen here is typical behaviour — initially large improvements are made very quickly, but as the population evolves the improvements become gradually more incremental. This is the main purpose for using a threshold value in normal experiments; to decide a cut-off point at which a solution is deemed good enough. Any further increases beyond this will normally provide small return compared to the time invested.

The linear plot is difficult to interpret by eye, so instead a logarithmic plot is preferable. Figure 2.20 shows the same data plotted on a log scale. This makes other features more clear, such as ‘plateauing’, where no improvement is seen for a number of generations before some chance mutation results in a number of quick improvements. Such features will be seen in the physical experiments described in later sections (Figure 2.38).

The speed and efficiency of the LabVIEW code compared to the MAT- LAB version was also checked to confirm the translation was both valid and appropriate. Using the settings described above, each version was given five runs and the number of generations required to reach a solution recorded.

Figure 2.19: Plot showing the evolution of the genetic algorithm towards a solution. The value of the fittest individual in each generation is plotted against generation number. The vertical scale here is linear.

Version Generations Version Generations MATLAB 10166 LabVIEW 10133 10019 8766 7251 10652 9451 9433 5701 8144

It is clear that the variable elements of the genetic algorithm mean that the number of generations taken to reach a solution can vary widely, even when using the exact same software. On the small sample above, there is no real evidence that, as far as the number of generations required is concerned, the algorithm performs any better or worse in LabVIEW than in MATLAB. As the algorithm is the same in each case, no difference should be expected so, rather than increase the number of samples to confirm this the issue of actual processing time was considered. Each algorithm was slightly adapted to record the time taken for a run from start to finish, and amended where necessary so that no data or information was plotted to the screen. Both algorithms were run on the same PC (Pentium 4 2.8 GHz with hyperthreading enabled, 2.5 GB of RAM)12. The results are shown below.

Version Gen. Time (s) Time/gen. (ms)

MATLAB 6643 23.92 3.60

5823 21.13 3.63

5866 20.97 3.57

7177 23.94 3.34

11725 43.55 3.71 Version Gen. Time (s) Time/gen. (ms) LabVIEW 9367 22.02 2.35

10382 24.98 2.41 12325 29.74 2.41

9237 22.33 2.42

9637 23.27 2.41

12For those of you reading this some years from now, yes, it does seem like an antiquated

Again the wide variation in the number of generations taken, and thus the overall time taken, can be clearly seen. However, the time taken to evaluate each generation is far more consistent, especially in the LabVIEW implementation. Also it is quite clear that the LabVIEW version processes each generation more quickly, in roughly two-thirds of the time in fact. Given that the number of generations taken to reach a solution is expected to average out as the same for both versions, the LabVIEW version can be expected to be faster, all else being equal.

Before implementing the genetic algorithm together with the pulse shaper it is necessary to have an understanding on the most appropriate starting parameters. These parameters are the population size and the number of offspring produced each generation. Although, theoretically, a correctly- designed algorithm should always converge on an optimal solution this is given an infinite amount of time. As the experimenter does not have an in- finite amount of time to run an experiment the initial parameters should be set so as to reach a satisfactory solution within some reasonable time frame. It is found that the actual times taken for processing are small, as in the timings given for the previous example in the table below.

Module Number of runs Average time (ms)

Recombine 9741 0.760 Mutate 9741 0.433 Select 9741 0.372 Ranking 9741 0.332 Reinsert 9740 0.091 Fitness 9742 0.006

The types of experiments for which the pulse shaping system is intended are mainly of the electro-optic sampling type (Section 3.5.1), where each evaluation will require a number of mechanically-delayed probe pulse mea- surements and thus will take far longer than a millisecond. Thus it will be the number of evaluations of individuals that determines the overall experimen- tal time, and it is this which should be minimised. For this reason a number

of tests were carried out to determine the relationship between population number, offspring proportion and the total number of evaluations.