Open lucasximenes opened 11 months ago
I think we can create a single benchmark function which receives a list of neighborhoods, a list of improvement types and a list of constructors, and performs a triple loop with all the parameters provided. This way, we can achieve the behavior described by the first benchmark function by passing a a list with a single neighborhood.
About the localSearch.jl file, I would like to add that the thought crossed my mind, but I ultimately decided not to because the domain of {i, j} pairs each neighborhood eval function accepts is different. That being said, we can move the validation of domain to inside the function, even though I think it's slightly suboptimal (extra function call), and have a much cleaner and elegant structure overall.
I'm creating this issue in order to discuss how we should structure our benchmark and also suggest a slight change on how we define our local search.
First of all, benchmarking.
I believe there should be 2 types of benchmarking in this project, the first is neighborhood performance, which is something among the lines of:
And the best overall neighborhood, which does the above test for each of the implemented neighborhoods. What do you guys think?
About local search, I believe we should create a file
LocalSearch.jl
orImprovements.jl
with the functionsbestImprovement
andfirstImprovement
, which would receive as parameters: the indices of the loop on which theeval
andmove
functions would be executed, the neighborhood struct, and finally, themove
andeval
functions.