Module org.cicirello.chips_n_salsa
Package org.cicirello.search.operators.permutations

Class ThreeOptMutation

java.lang.Object
org.cicirello.search.operators.permutations.ThreeOptMutation
All Implemented Interfaces:
Splittable<MutationOperator<Permutation>>, MutationOperator<Permutation>, UndoableMutationOperator<Permutation>
public final class ThreeOptMutation extends Object implements UndoableMutationOperator<Permutation>
This class implements the classic 3-Opt neighborhood as a mutation operator for permutations. The 3-Opt neighborhood includes all two-changes and all three-changes. These originated specifically for the TSP. A two-change for the TSP removes two edges from a tour of the cities of a TSP and replaces them with two different edges such that the result is a valid tour of the cities. Likewise, a three-change removes three edges from the tour of the cities of a TSP and replaces them with three different edges. This implementation is not strictly for the TSP, and will operate on a permutation regardless of what that permutation represents. However, it assumes that the permutation represents a cyclic sequence of undirected edges, and specifically that if two elements are adjacent in the permutation that it corresponds to an undirected edge between the elements. For example, consider the permutation, p = [2, 1, 4, 0, 3], of the first 5 non-negative integers. Now imagine that we have a graph with 5 vertexes, labeled 0 to 4. This example permutation would correspond to a set of undirected edges: { (2, 1), (1, 4), (4, 0), (0, 3), (3, 2) }. Notice that we included (3, 2) here in that the set of edges represented by the permutation is cyclic and includes an edge between the two endpoints.

The runtime (worst case and average case) of both the mutate and undo methods is O(n), where n is the length of the permutation.

For any given permutation of length n, there are n*(n-3)/2 possible two-change neighbors, and 4*(n*(n-1)*(n-2)/6 - n*(n-4) - n) + n*(n-4) possible three-change neighbors. Each of the possible three-changes is approximately equally likely as every other three-change. Each of the possible two-changes is approximately equally likely as every other two-change. The current implementation does not guarantee that each of the possible two-changes are equally likely as each of the possible three-changes. Currently, each two-change is slightly more likely than each three-change. Although because the number of possible three-changes grows cubicly vs quadratic growth in number of possible two-changes, the probability of a three-change increases rapidly as permutation length increases.

For permutations of length equal to 4, the ThreeOptMutation will only perform two-changes because no valid three-changes exist for that length. For permutations of length n < 4, the ThreeOptMutation operator makes no changes, as there are no two-change or three-change neighbors of permutations of that size.

  • Constructor Details

    • ThreeOptMutation

      public ThreeOptMutation()
      Constructs a ThreeOptMutation operator.

  • Method Details

    • mutate

      public void mutate(Permutation c)
      Description copied from interface: MutationOperator
      Mutates a candidate solution to a problem, by randomly modifying its state. The mutant that is produced is in the local neighborhood of the original candidate solution.
      Specified by:
      mutate in interface MutationOperator<Permutation>
      Parameters:
      c - The candidate solution subject to the mutation. This method changes the state of c.

    • undo

      public void undo(Permutation c)
      Description copied from interface: UndoableMutationOperator
      Returns a candidate solution to its previous state prior to the most recent mutation performed.

      For example, consider the following. Let c' be the current state of c. Let c'' be the state of c after mutate(c); If we then call undo(c), the state of c should revert back to c'.

      The behavior of undo is undefined if c is altered by some other process between the calls to mutate and undo. The behavior is also undefined if a different candidate is given to undo then the last given to mutate. For example, if the following two statements are executed, mutate(c); undo(d);, the effect on d is undefined as it wasn't the most recently mutated candidate solution.

      Specified by:
      undo in interface UndoableMutationOperator<Permutation>
      Parameters:
      c - The candidate solution to revert.

    • split

      public ThreeOptMutation split()
      Description copied from interface: Splittable
      Generates a functionally identical copy of this object, for use in multithreaded implementations of search algorithms. The state of the object that is returned may or may not be identical to that of the original. Thus, this is a distinct concept from the functionality of the Copyable interface. Classes that implement this interface must ensure that the object returned performs the same functionality, and that it does not share any state data that would be either unsafe or inefficient for concurrent access by multiple threads. The split method is allowed to simply return the this reference, provided that it is both safe and efficient for multiple threads to share a single copy of the Splittable object. The intention is to provide a multithreaded search with the capability to provide spawned threads with their own distinct search operators. Such multithreaded algorithms can call the split method for each thread it spawns to generate a functionally identical copy of the operator, but with independent state.
      Specified by:
      split in interface Splittable<MutationOperator<Permutation>>
      Specified by:
      split in interface UndoableMutationOperator<Permutation>
      Returns:
      A functionally identical copy of the object, or a reference to this if it is both safe and efficient for multiple threads to share a single instance of this Splittable object.