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

Class 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 Detail

      • TwoChangeMutation

        public TwoChangeMutation()
        Constructs an TwoChangeMutation mutation operator.

    • Method Detail

      • 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.