Detecting Convergence

Like the initialisation strategies, convergence detection should also be designed specif- ically for the application. In applications that do not have strict run-time constraints efficient convergence detection is not of great concern and simply halting the optimisa- tion after a maximum number of iterations were reached is usually sufficient. However, in real-time applications or in applications where a timely execution is preferable, con- vergence detection is very important.

As mentioned, the simplest approach is to count the number of iterations and stop when some maximum has been reached. This approach has the advantage of not adding any extra computational overhead and being the easiest to implement. The run-time versus accuracy trade-off can be accurately controlled by setting the maximum number of iterations low for quick execution and high for slower execution but potentially better accuracy. The disadvantage of this approach is that many iterations are likely being wasted since the optimiser will only halt when the maximum iterations have been reached even when the optimal solution has stopped improving.

In time critical applications it is important to detect when the optimiser will likely not be able to improve on the current solution any further. Optimisation should then immediately be stopped to prevent wasted iterations. A simple way to minimise wasted idle iterations is to count the number of consecutive idle iterations and halt optimisation when a set number of consecutive idle iterations have been counted. An idle iteration is identified as an iteration in which the HM is not updated. In other words, the newly improvised solution is worse than the worst solution in the HM and is therefore discarded without affecting the HM.

The danger of this approach lies in the assumption that multiple consecutive idle iterations imply that no further progress will be made. As is often the case, the majority of candidate solutions in the HM may be in the basin of attraction of a local optimum that is not the global optimum. The more solutions close to the local optimum the longer it will take to escape the basin of attraction and generate an improvisation that is good enough to update HM. It might take many idle iterations before a new local optimum is found starting a new series of updates to the HM. The number of idle iterations to allow before halting should therefore be carefully chosen specific to the search space to prevent premature convergence to suboptimal solutions.

Another approach that does not rely on counting idle iterations is to measure the diversity in the quality of the solutions directly. Eventually, all the candidate solutions will converge to the same basin of attraction and gradually come together until they all equal the same optimum. By measuring the Euclidean distance between the best and the worst candidate in the HM we can get a measure of how closely the candidates have converged towards the same solution. When this distance is smaller than some set amount, , the HM is considered converged and the optimiser halts. Normally one chooses proportional to the desired accuracy, setting equal to the largest error one is willing to make. However, depending on the size of the HM this may take very long for all the candidates in the HM to move close enough together and a larger is usually more practical. Given a large enough initial diversity in the HM, this is usually the safest way of convergence detection but some iterations are still wasted since it is unnecessary to wait for all the candidates in the HM to converge when only one equal to the optimum is required. Dr Z.W. Geem suggests (in a private correspondence) that the FW can be decreased when convergence is first suspected in an attempt to inject diversity into the HM without immediately halting convergence. This could allow for more sensitive convergence detection resulting in less wasted iterations while minimising the risk of premature convergence.

A good trade-off between the advantages of all the previously mentioned methods is to combine them into a set of tests. If any of the tests indicate convergence, the optimiser halts and the best solution in the HM is considered the optimal solution. If

and the maximum number of idle iterations are chosen carefully this method is very efficient in quickly detecting convergence with the minimum of iterations wasted. As we will see in Section 3.4, it is even possible to do real-time video tracking using this

2.5 Implementation Details

method for convergence detection. A pseudo code implementation of the combined convergence tests is shown in Algorithm 2.5.

input : A non-converged HM

input :g= the current number of iterations

input :gidle= the current number of iterations input :Gmax= the maximum iterations allowed

input :GidleM ax= the maximum idle iterations allowed output: The convergence status of the HM

1 if g_idle> G_{idleM ax} then // check idle iterations

2 HALT optimisation

3 // HMbest and HMworst are the best and worst members of the HM

4 else if |HM_best−HM_worst|< then // check diversity

5 HALT optimisation

6 else if g > Gmax then // check max generations

7 HALT optimisation 8 else

9 CONTINUE with new improvisation 10 end

Algorithm 2.5: Combined convergence tests

The regular testing for convergence using diversity measurements and the counting of idle iterations in real-time applications has not been applied to harmony search before and is a novel contribution of this research. I introduced this method in [24] with further details in [23].