This optimized version of the Modified Lam is described in the following article:
Vincent A. Cicirello. 2020. Optimizing the Modified Lam Annealing Schedule. Industrial Networks and Intelligent Systems, 7(25): 1-11, Article e1 (December 2020). doi:10.4108/eai.16-12-2020.167653. [PDF] [BIB]
This optimized Java implementation is significantly faster than the implementation that would result from a direct implementation as described originally by Boyan (1998). Specifically, in the original Boyan's Modified Lam, the update of the target rate of acceptance involves an exponentiation. This update occurs once for each iteration of simulated annealing. However, in the Optimized Modified Lam of Cicirello (2020), the target rate is instead computed incrementally from the prior rate. If the simulated annealing run is n evaluations in length, then the direct implementation of Boyan's Modified Lam schedule performs n/2 exponentiations in total across all updates of the target rate; while the Optimized Modified Lam instead perform only 2 exponentiations and n/2 multiplications total across all updates of the target rate. The schedule of target acceptance rates is otherwise the same.
For details of the original Modified Lam schedule, such as its origins and rationale, see the following references:
- Lam, J., and Delosme, J. 1988. Performance of a new annealing schedule. In Proc. 25th ACM/IEEE DAC, 306–311.
- Swartz, W. P. 1993. Automatic Layout of Analog and Digital Mixed Macro/Standard Cell Integrated Circuits. Ph.D. Dissertation, Yale University.
- Boyan, J. A. 1998. Learning Evaluation Functions for Global Optimization. Ph.D. Dissertation, Carnegie Mellon University, Pittsburgh, PA.
The Chips-n-Salsa library also includes an implementation of the original Modified Lam
schedule that is the result of a direct implementation of Boyan's description of the annealing
schedule, see the
ModifiedLamOriginal class for that version.
accept(double, double) methods of this class use the classic, and most common, Boltzmann
distribution for determining whether to accept a neighbor.
Constructor SummaryConstructorDescriptionDefault constructor.
Method SummaryModifier and TypeMethodDescription
(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.
(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.
ModifiedLampublic ModifiedLam()Default constructor. The Modified Lam annealing schedule, unlike other annealing schedules, has no control parameters other than the run length (the maxEvals parameter of the
init(int)method), so no parameters need be passed to the constructor.
initpublic void init
(int maxEvals)Description copied from interface:
AnnealingSchedulePerform 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:
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.
acceptpublic boolean accept
(double neighborCost, double currentCost)Description copied from interface:
AnnealingScheduleDetermine 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.
splitpublic ModifiedLam split()Description copied from interface:
SplittableGenerates 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
Copyableinterface. 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.