Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve heuristic choices when using lots of skills #1193

Closed
jcoupey opened this issue Nov 22, 2024 · 2 comments · Fixed by #1194
Closed

Improve heuristic choices when using lots of skills #1193

jcoupey opened this issue Nov 22, 2024 · 2 comments · Fixed by #1194

Comments

@jcoupey
Copy link
Collaborator

jcoupey commented Nov 22, 2024

Over time, we've changed things that have subtle impacts on the heuristic choices to build initial solutions. For example #648 indirectly impacts vehicle ordering, #982 impacts regrets computations, etc.

We have examples showing that altogether those changes induced a regression in solution quality (especially number of assigned jobs) for some instances with complex skills setups. See #1102 (comment), I'm opening this ticket to track improving that situation since the initial ticket is somehow mixed with a different problem.

cc @do-me

@jcoupey
Copy link
Collaborator Author

jcoupey commented Nov 22, 2024

After investigating with some compared execution analysis on several instances, I think the reason for the change is mainly related to a side-effect of #982.

A consequence of #982 is that when we evaluate the regret for not inserting a job while building an initial route, we now account for the fact that the job is compatible with the remaining, yet unused, vehicles. Let's say we have a job j compatible with vehicle v for which we're currently building the route in basic heuristic. If j is not compatible with any of the remaining vehicles after v, then its regret now gets a prohibitive value. This is actually desirable: when choosing between inserting j over another j2 that is doable by another remaining vehicle, then we'll pick j as j2 will have a much smaller regret value.
Put it differently: this makes sure that we hint toward inserting jobs whose "last chance" are the current vehicle.

So far so good. Now imagine a setup where none of the available jobs are doable by other vehicles. Then they all get the same prohibitive value as regret, and the ponderation we use to decide insertion has no effect. The problem is not really that regret values are prohibitive, it's that they're all identical. This defeats the purpose of using various regret ponderations (lambda values) in heuristic tunings since all tunings will yield the same insertion choices.

The consequence in that case is a poorer variety of exploration across heuristic parameters than before, when regrets used to not be all equal in that specific setup.

@jcoupey jcoupey mentioned this issue Nov 22, 2024
5 tasks
@jcoupey
Copy link
Collaborator Author

jcoupey commented Nov 25, 2024

For the record, I've been able to reproduce a similar behavior on variant instances with heterogeneous vehicle locations that trigger the dynamic heuristic, which means we have to apply the same kind of fix to that too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant