Add a way to specify a custom move function #2
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What
Implements the first proposed change in #1
Why
Metal#swap_collection
assumes that the collection is a singe-dimension array and a neighboring state can be found by swapping elements. In my case, I'm working with a two dimensional array and neighboring states are created from shifting elements of one internal array to another. There are likely other use cases that might call for more complicated object manipulations. Being able to specify a custom move function that receives the current state and returns the next state would allow this library to be able to anneal more complex objects.How
state
rather thancollection
total_energy_calculator
toenergy_calculator
for brevity and consistencyenergy_calculator
lambda. It assumed a collection ofLocation
objects. Users must now specify their ownenergy_calculator
function based on the object they are annealing.state_change
method, replacingMetal#swap_collection
. Users must specify their ownstate_change
function based on the object they are annealing.energy_calculator
orstate_change
functionsbin/run
scriptNote that the original proposal was:
I purposely chose not to default to the previous implementation of
Metal#swap_collection
as that assumed that the initial state was an enumerable, which it isn't guaranteed to be. IMO it's better that we require the user to provide their own method based on whatever object they are annealing.