Class ParameterFreeExponentialCooling
 All Implemented Interfaces:
Splittable<AnnealingSchedule>
,AnnealingSchedule
init(int)
method.
In exponential cooling, the kth temperature, t_{k}, is determined as follows: t_{k} = α^{k} * t_{0}, where t_{0} is the initial temperature and α is the cooling rate. The new temperature is usually computed incrementally from the previous with: t_{k} = α * t_{k1}. In some applications, the temperature update occurs with each simulated annealing evaluation, while in others it is updated periodically, such as every s steps (i.e., iterations) of simulated annealing.
The accept
method of this class use the classic, and most common, Boltzmann
distribution for determining whether to accept a neighbor. With the Boltzmann distribution,
simulated annealing accepts a neighbor with higher cost than the current state with probability
e^{(cn)/t} where c is the cost of the current state, n > c is the cost of the random
neighbor, and t is the current temperature. Note that if n ≤ c, then simulated annealing
always accepts the neighbor.
A classic approach to setting the initial temperature t_{0} is to randomly sample the space of solutions to compute an estimate of ΔC, the average difference in cost between random neighbors, and to then set t_{0} = ΔC / ln(P), where P < 1 is an initial target acceptance probability near 1. To see why, plug ΔC / ln(P) into the Boltzmann distribution for t, and assume the cost c of the current state and the neighbor cost n exhibits the average difference, then you'd derive the following acceptance probability e^{(cn)/t} = e^{(cn)/(ΔC / ln(P))} = e^{ΔC/(ΔC / ln(P))} = e^{ln(P)} = P.
We use the following variation of this approach to determine an initial temperature. We initially accept all neighbors until we have seen 10 transitions between states with different cost values. We then use those 10 transitions to compute ΔC, by averaging the absolute value of the difference in costs across the 10 pairs of neighboring solutions, and set t_{0} = ΔC / ln(0.95).
We then set α and steps (number of transitions between temperature changes) based on the
run length specified in the maxEvals parameter of init(int)
such that the temperature t
declines to 0.001 by the end of the run. Specifically, we set α = (0.001 /
t_{0})^{1 / ceiling(k / steps)}, where k is the number of remaining iterations
(maxEvals reduced by the number of iterations necessary to obtain the 10 samples used to compute
t_{0}) and where steps is set to the lowest power of 2 such that the α we compute
is α ≤ 0.999. The rationale for setting steps to a power of 2 is for efficiency in
computing α and steps (start steps at 1 and double until α is in target range,
relatively few iterations necessary). The rationale for setting α ≤ 0.999 is to avoid
any numerical issues that may arise from repeatedly multiplying by a value that is very close to
1.0.

Constructor Summary
ConstructorDescriptionConstructs a exponential cooling schedule that uses first few samples to estimate cost difference between random neighbors, and then uses that estimate to set the initial temperature, alpha, and step size. 
Method Summary
Modifier and TypeMethodDescriptionboolean
accept
(double neighborCost, double currentCost) Determine whether or not to accept a neighboring solution based on its cost and the current cost, both passed as parameters.void
init
(int maxEvals) Perform any initialization necessary for the annealing schedule at to the start of a run of simulated annealing.split()
Generates a functionally identical copy of this object, for use in multithreaded implementations of search algorithms.

Constructor Details

ParameterFreeExponentialCooling
public ParameterFreeExponentialCooling()Constructs a exponential cooling schedule that uses first few samples to estimate cost difference between random neighbors, and then uses that estimate to set the initial temperature, alpha, and step size.


Method Details

init
public void init(int maxEvals) Description copied from interface:AnnealingSchedule
Perform any initialization necessary for the annealing schedule at to the start of a run of simulated annealing. This includes initializing the temperature parameter. This method is called once by implementations of simulated annealing at the start of the run. Implementations of simulated annealing that perform reannealing will also call this once at the start of each reanneal. Specified by:
init
in interfaceAnnealingSchedule
 Parameters:
maxEvals
 The maximum length of the run of simulated annealing about to start. Some annealing schedules depend upon prior knowledge of run length. For those annealing schedules that don't depend upon run length, this parameter is ignored.

accept
public boolean accept(double neighborCost, double currentCost) Description copied from interface:AnnealingSchedule
Determine whether or not to accept a neighboring solution based on its cost and the current cost, both passed as parameters. Lower cost indicates better solution. This method must also update the temperature and any other state data related to the annealing schedule. Specified by:
accept
in interfaceAnnealingSchedule
 Parameters:
neighborCost
 The cost of the neighboring solution under consideration.currentCost
 The cost of the current solution. Returns:
 true if simulated annealing should accept the neighbor, and false otherwise.

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