Skip to content

Fix heuristic time going past timeout#807

Merged
jcoupey merged 3 commits intomasterfrom
fix/heuristic-time-over-timeout
Oct 27, 2022
Merged

Fix heuristic time going past timeout#807
jcoupey merged 3 commits intomasterfrom
fix/heuristic-time-over-timeout

Conversation

@jcoupey
Copy link
Copy Markdown
Collaborator

@jcoupey jcoupey commented Oct 21, 2022

Issue

This PR cherry-picks stuff from #755 that I tried back then but discarded at the time. The idea is to:

Tasks

  • Split multithreading part in two: first heuristics then local search
  • Spot and remove identical heuristic solutions based on solution indicators values
  • Update CHANGELOG.md
  • review

@kkarbowiak
Copy link
Copy Markdown
Contributor

It looks like both CVRP::solve() and VRPTW::solve() functions have grown and became more (too) complex, but we can remedy this with a couple steps.

It seems both functions are identical, except for two details:

  1. CVRP::solve() starts with a part that falls back to simpler TSP problem.
  2. CVRP::solve() operates on RawRoute and RawSolution types, while VRPTW::solve() operates on TWSolution and TWRoute respectively.

Regarding 1. Could this check be extracted to Input::get_problem() function, so it returns the simpler problem instance?

Regarding 2. We could have a template function parametrised with Route and Solution types that would handle both cases. This would replace two functions with one. A further improvement could be gained by extracting handling threads to a separate class.

I can make some commits on top of this branch to show what I have in mind.

@jcoupey
Copy link
Copy Markdown
Collaborator Author

jcoupey commented Oct 26, 2022

You're right, the reason for having nearly similar duplicated implementation in the first place is that they were simple enough to not bother going through an additional abstraction layer. It would be a nice refactor to change that now.

Regarding 1. Could this check be extracted to Input::get_problem() function, so it returns the simpler problem instance?

Definitely would make sense. We'd simply have to add a TSP(const Input& input) ctor.

Agree on using templates for the core solving code. Another thing to consider here is that we use 4 different parameter sets for all cvrp/vrptw X homogeneous/heterogeneous options.

Also happy to have the threads code live somewhere else if it makes the code more expressive and easy to read.

I can make some commits on top of this branch to show what I have in mind.

Since this PR was originally a fix and we're talking about a more thorough refactor, I'd be in favor of merging as is now and moving the refactor part to another issue, what do you think?

@kkarbowiak
Copy link
Copy Markdown
Contributor

Since this PR was originally a fix and we're talking about a more thorough refactor, I'd be in favor of merging as is now and moving the refactor part to another issue, what do you think?

Makes sense.

@jcoupey jcoupey merged commit 7493458 into master Oct 27, 2022
@jcoupey jcoupey deleted the fix/heuristic-time-over-timeout branch October 27, 2022 08:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Timeout option has no effect

2 participants