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

Class TwoChangeMutation

java.lang.Object
org.cicirello.search.operators.permutations.TwoChangeMutation
All Implemented Interfaces:
Splittable<MutationOperator<Permutation>>, IterableMutationOperator<Permutation>, MutationOperator<Permutation>, UndoableMutationOperator<Permutation>
public final class TwoChangeMutation extends Object implements UndoableMutationOperator<Permutation>, IterableMutationOperator<Permutation>
This class implements the classic two-change operator as a mutation operator for permutations. The two-change operator originated as a local search operator for the TSP that 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. 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 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 classic two-change removes two edges and replaces them with two different edges that reconnect a valid traversal of all elements. One way of implementing the equivalent of this as an operator on permutations is to reverse a subsequence. For example, consider reversing the first 3 elements, which gives you: p = [4, 1, 2, 0, 3], which under the edge interpretation corresponds to the edges: { (4, 1), (1, 2), (2, 0), (0, 3), (3, 4) }. Remember that we are interpreting the edges as undirected edges, and that there are exactly two that have changed: (4, 0) and (3, 2) were removed, and replaced by (2, 0) and (3, 4).

Technically, if you wanted to use the approximate equivalent of a two change operator, you could use the ReversalMutation class. The reason is that every two change is equivalent to a reversal. However, not every reversal is equivalent to a two change. If you reverse the entire permutation, you don't actually change any edges, if the permutation represents a cyclic set of undirected edges. Likewise, if you reverse an n-1 length sequence of elements, you also don't change any edges. This TwoChangeMutation class implements a two change operator that always produces a mutant that is the equivalent to changing two edges (if that is what the permutation represents). For example, it won't reverse the entire permutation, and also won't reverse a subpermutation of length n-1. Additionally, simply viewing reversals as two changes leads to redundancy (e.g., reversing the first k elements changes the same two edges as reversing the last n-k elements), so if your aim is to perform two changes, and if you want all possible two changes to be equally likely when generating a random mutant, then the ReversalMutation class will not give you that since it will be biased in favor of the two changes that have multiple equivalent reversals. This TwoChangeMutation class is implemented such that all two changes of a permutation are approximately equally likely.

Also note that this TwoChangeMutation doesn't guarantee implementation by reversals. It only guarantees that every mutation is equivalent to a two change (under the interpretation of a permutation representing a cyclic set of edges), and that all possible such two changes are equally likely. Under this assumption some two changes can be generated faster than by a reversal.

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. During a single call to one of these methods, at most n/2 elements will change locations. Thus, this is roughly twice as fast as the ReversalMutation class, which can move as many as n elements during a single call to these methods. If the set of edges interpretation applies to your problem, then the TwoChangeMutation may be a better choice than ReversalMutation. At the very least it will compute mutants faster. If that interpretation doesn't apply to your problem, then we can't really say (at least not in a problem independent way) which might be better.

For any given permutation of length n, there are n*(n-3)/2 possible two-change neighbors. For permutations of length n < 4, the TwoChangeMutation operator makes no changes, as there are no two-change neighbors of permutations of that size.

  • Constructor Summary

    Constructors
    Constructor
    Description
    TwoChangeMutation()
    Constructs an TwoChangeMutation mutation operator.

  • Method Summary

    Modifier and Type
    Method
    Description
    MutationIterator
    iterator(Permutation p)
    Creates and returns a MutationIterator that can be used to systematically iterate over all of the direct neighbors (i.e., a single mutation step away) of a candidate solution, as one might do in a hill climber.
    final void
    mutate(Permutation c)
    Mutates a candidate solution to a problem, by randomly modifying its state.
    TwoChangeMutation
    split()
    Generates a functionally identical copy of this object, for use in multithreaded implementations of search algorithms.
    final void
    undo(Permutation c)
    Returns a candidate solution to its previous state prior to the most recent mutation performed.

    Methods inherited from class java.lang.Object

    clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

  • Constructor Details

    • TwoChangeMutation

      public TwoChangeMutation()
      Constructs an TwoChangeMutation mutation operator.

  • Method Details

    • mutate

      public final 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 final 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 TwoChangeMutation 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 IterableMutationOperator<Permutation>
      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.

    • iterator

      public MutationIterator iterator(Permutation p)
      Creates and returns a MutationIterator that can be used to systematically iterate over all of the direct neighbors (i.e., a single mutation step away) of a candidate solution, as one might do in a hill climber.

      The worst case runtime of the MutationIterator.hasNext() and the MutationIterator.setSavepoint() methods of the MutationIterator created by this method is O(1). The amortized runtime of the MutationIterator.nextMutant() method is O(1). And the worst case runtime of the MutationIterator.rollback() method is O(n), where n is the length of the Permutation.

      Specified by:
      iterator in interface IterableMutationOperator<Permutation>
      Parameters:
      p - The candidate solution subject to the mutation. Calling methods of the MutationIterator that is returned changes the state of that candidate solution. See the documentation of those methods for details of how such changes may occur.
      Returns:
      A MutationIterator for iterating over the direct neighbors of a candidate solution.