Class TwoChangeMutation
- All Implemented Interfaces:
Splittable<MutationOperator<Permutation>>
,IterableMutationOperator<Permutation>
,MutationOperator<Permutation>
,UndoableMutationOperator<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 -
Method Summary
Modifier and TypeMethodDescriptionCreates and returns aMutationIterator
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
Mutates a candidate solution to a problem, by randomly modifying its state.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.
-
Constructor Details
-
TwoChangeMutation
public TwoChangeMutation()Constructs an TwoChangeMutation mutation operator.
-
-
Method Details
-
mutate
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 interfaceMutationOperator<Permutation>
- Parameters:
c
- The candidate solution subject to the mutation. This method changes the state of c.
-
undo
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 interfaceUndoableMutationOperator<Permutation>
- Parameters:
c
- The candidate solution to revert.
-
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 theCopyable
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 interfaceIterableMutationOperator<Permutation>
- Specified by:
split
in interfaceSplittable<MutationOperator<Permutation>>
- Specified by:
split
in interfaceUndoableMutationOperator<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
Creates and returns aMutationIterator
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 theMutationIterator.setSavepoint()
methods of theMutationIterator
created by this method is O(1). The amortized runtime of theMutationIterator.nextMutant()
method is O(1). And the worst case runtime of theMutationIterator.rollback()
method is O(n), where n is the length of the Permutation.- Specified by:
iterator
in interfaceIterableMutationOperator<Permutation>
- Parameters:
p
- The candidate solution subject to the mutation. Calling methods of theMutationIterator
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.
-