You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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
The text was updated successfully, but these errors were encountered: