Fixed Length

In contrast to the encoding used in the original work (Chapter 4, [WM22b]), which used a variable-length encoding, most algorithm frameworks are — by

default — configured with fixed numbers of variables. Here, we propose a real-valued and a binary representation scheme, respectively.

Moreover, in the original graph representation of the problem, obstacles in the map were avoided by removing their nodes from the graph. However, in our approach, coordinates in the map could be created that contained obstacles (which render a path infeasible). Hence, we propose two different ways of handling infeasible solutions in our encodings [WZM21].

Real-valued Encoding

For the real-valued encoding, each variable represents one step of movement on the grid-based map. Based on the chosen neighbourhood, obstacles and other parameters, different directions of movement are possible from any given location in the grid. As a result, each variable represents the direction to move in during the next step while traversing the path. Because we define a fixed-length encoding, using this pattern, only a fixed number of steps is possible.

The maximum number of direction changes for a path from one corner to the opposite corner is defined by the map’s size, i.e.,d_max =x_max+y_max− 2. We propose multiplying this number by a certain factor δ because of the benchmark’s ability to represent maps where backtracking is allowed. Hence, the destination can be reached even if directions are used, which increase the distance to the end coordinates in suboptimal solutions or when obstacles have to be avoided. In the experiments, we evaluate the impact of different values of δ. The total number of decision variables is defined asD=⌈d_max·δ⌉.

Decoding is implemented from the real-valued vector⃗r, which translates the real values into coordinates in the grid, i.e., a list of nodes. This list is then used in the original evaluation functions of the problem, as shown in Chapter 4.

For each decision variable ri, we define the domain ri ∈[0,1]. During the evaluation, this interval is divided into the number of possible neighbours of a cell; therefore, each sub-interval maps to another direction in the following way.

For each variableri, determine the neighboursnneighboursof the current grid cell.

Then, divide the interval[0,1]intonneighboursparts. The value ofri determines which neighbour is used and which step is added to the path [WZM21].

Binary Encoding

The binary encoding uses a number of bits necessary to express the possi-ble neighbouring nodes according to the chosen neighbourhood structure for every decision. One individual consists of a binary vector #»

b = (b1,· · ·,b_D), where bi ∈ {0,1}, for i = 1,· · ·,D. In the same way as in the real en-coding, we employ the factor δ to increase the likelihood of reaching the goal. The number of decision variables with this encoding is defined by D=

(

log₂(nneighbours)

+1)·d_max·δ

. The value ofn_neighbours depends on the benchmark’s setting regarding the 2^k-neighbourhood and the backtracking setting. Since we need

log₂(nneighbours)

+1 bits to encode one change in direction, we map the respective number of bits to a number in the interval of[0,1]and decode the path using the same methodology as in the real-value encoding [WZM21].

Neighbour Calculation

In both proposed encodings, the number of existing neighboursn_neighboursmust be computed for each grid cell. The number of neighbours is influenced by the

problem’s parameters, i.e., the neighbourhood (k=2 ork=3), and by whether backtracking is allowed on paths. For instance, ifk=2 and backtracking is allowed, there are four possible neighbours: east, south, west and north. By contrast, without backtracking, the traversal is allowed only to the east and the south. On the other hand, with ak=3 neighbourhood, the diagonal directions would also be allowed. Furthermore, cells at the edges of the map may possess fewer neighbouring cells. In addition, the existence of obstacles in the map can lead to smaller numbers of neighbours for the cells next to the obstacle cells.

In our encoding, the movement towards a neighbouring cell is always computed with only the available neighbours. This means that in cases where backtracking is not allowed and the current position lies on the right border of the map, the only remaining neighbour is the cell below. Hence, no matter which value the following real or binary-encoded movement contains, the outcome is always the same neighbour [WZM21].

Constraint Handling

Constraint handling methodologies are necessary for the fixed-length encodings to tackle two separate challenges: (1) the produced paths do not necessarily arrive at the designated destination position, i.e.,(xmax,ymax)in the map, and (2) the encodings may be able to produce paths that traverse through grid cells with obstacles on them.

While the original implementation reported in [WM22b] always operated on feasible paths with a fixed start and destination, the proposed fixed-length encoding does not guarantee arrival at the destination. Instead, the decisions on which direction to take in each grid cell can, independent of binary or real-valued encoding, result in a path that stops at arbitrary coordinates.

To account for this circumstance and enable arbitrary algorithms to produce optimal paths, we utilise penalty values to decrease the quality of incomplete paths. More precisely, if the target destination is not reached within the length of an individual (i.e., the fixed number of steps), a penalty value of twice the Manhattan distance from the current position to the destination is added to the first objective value f₁, which represents the length of the path. This value is chosen because it represents a longer distance than the longest distance necessary to reach the goal from the current position; therefore, the objective function value for f₁is worse for a solution that does not arrive at the destination than for the worst solution that does arrive. Other approaches have used different constraint handling techniques [Deb00], which are not accounted for in this implementation.

The second issue concerns obstacle handling. In this thesis, we compare two methods of dealing with obstacles. The first is not to allow obstacles on the paths, which means removing the neighbouring cells from the list of possible neighbours if they contain obstacles. This version is most similar to the original implementation of ASLETISMAC , as it does not allow obstacles on the path.

The second approach allows our encoding to produce arbitrary paths even if they contain obstacle cells. Such paths are not beneficial for the underlying pathfinding application. Therefore, a cell containing obstacles in a path is penalised by adding the number of obstacles contained to the first objective function f₁.

For the analysis, we consider solutions that do not arrive at the destination or traverse obstacles as infeasible [WZM21].