Class PartiallyMatchedCrossover
 All Implemented Interfaces:
Splittable<CrossoverOperator<Permutation>>
,CrossoverOperator<Permutation>
Consider as an example parent permutation p1 = [0, 1, 2, 3, 4, 5, 6, 7] and parent permutation p2 = [1, 2, 0, 5, 6, 7, 4, 3]. Now consider that the random cross region begins at index 2 and ends at index 4, inclusive. Child c1 is initialized as a copy of p1, c1 = [0, 1, 2, 3, 4, 5, 6, 7], and we then swap the 2 with the 0 (the elements at index 2 in the parents) to get c1 = [2, 1, 0, 3, 4, 5, 6, 7]. Next, we swap the 3 with the 5 (the elements at index 3 in the parents) to get c1 = [2, 1, 0, 5, 4, 3, 6, 7]. Finally, we swap the 4 with the 6 (the elements at index 4 in the parents) to end up with c1 = [2, 1, 0, 5, 6, 3, 4, 7]. In a similar way, we initialize c2 as a copy of p2 and proceed with the designated swaps to end up with c2 = [1, 0, 2, 3, 4, 7, 6, 5].
PMX was introduced in the following paper:
Goldberg, D.E. and Lingle, R. Alleles, Loci, and the Traveling Salesman Problem. Proceedings
of the 1st International Conference on Genetic Algorithms, 1985, pp. 154159.
Although, we actually relied on the seminal book on genetic algorithms by one of PMX's authors
David E Goldberg:
Goldberg, D.E. Genetic Algorithms in Search, Optimization and Machine Learning, Addison
Wesley, 1989.
Note that this implementation in ChipsnSalsa is asymptotically faster than Goldberg and
Lingle's algorithmic description of PMX. In the original PMX description, the indexes of the
elements to swap were found with a linear search, and since on average there is a linear number
of these, PMX as originally described required O(n^{2}) time. However, the implementation
here in ChipsnSalsa computes the inverse of each permutation in linear time, which is then used
as a lookup table for the indexes of the elements to swap. Each swap is constant time, and also
involves a constant time update to the lookup table of indexes. Thus, this implementation, the
cross
method, has an average case and worst case runtime of O(n), where n is
permutation length.

Constructor Summary
ConstructorDescriptionConstructs a partially matched crossover (PMX) operator. 
Method Summary
Modifier and TypeMethodDescriptionvoid
cross
(Permutation c1, Permutation c2) Performs a crossover for an evolutionary algorithm, such that crossover forms two children from two parents.split()
Generates a functionally identical copy of this object, for use in multithreaded implementations of search algorithms.

Constructor Details

PartiallyMatchedCrossover
public PartiallyMatchedCrossover()Constructs a partially matched crossover (PMX) operator.


Method Details

cross
Description copied from interface:CrossoverOperator
Performs a crossover for an evolutionary algorithm, such that crossover forms two children from two parents. Implementations of this method modify the parameters, transforming the parents into the children. Specified by:
cross
in interfaceCrossoverOperator<Permutation>
 Parameters:
c1
 A candidate solution subject to the crossover. This method changes the state of c1.c2
 A candidate solution subject to the crossover. This method changes the state of c2.

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 interfaceSplittable<CrossoverOperator<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.
