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
Rationale: in a typical situation with TW or capacity constraints, there are implicit max_tasks values existing for all vehicles. Say for example a vehicle has "capacity": [50] and all jobs have "delivery": [5] (or more), then this vehicle won't ever have a route with more than 10 jobs in it.
Though explicitly providing "max_tasks": 10 does not change the problem model (and solution), it does have a significant impact on computing time. Indeed, any move that would result in a route over 10 jobs for this vehicle is now discarded without even looking up its potential cost and ending up noticing it's invalid anyway. Actually the C++ object for the local search operator is not even created.
It feels weird to have equivalent models (with or without max_tasks) resulting in significantly different computing times for the exact same solution. It's also not satisfactory to require users to provide additional constraints for a reason that is tightly coupled with the internal solving process, not to mention that coming up with the right limits may not always be trivial in the first place.
So we should setup a way to derive those implicit constraints automatically and lower max tasks values accordingly for vehicles. Also, this is a great opportunity to speed up things for instances that naturally contain strong implicit constraints.
The text was updated successfully, but these errors were encountered:
Rationale: in a typical situation with TW or capacity constraints, there are implicit
max_tasks
values existing for all vehicles. Say for example a vehicle has"capacity": [50]
and all jobs have"delivery": [5]
(or more), then this vehicle won't ever have a route with more than 10 jobs in it.Though explicitly providing
"max_tasks": 10
does not change the problem model (and solution), it does have a significant impact on computing time. Indeed, any move that would result in a route over 10 jobs for this vehicle is now discarded without even looking up its potential cost and ending up noticing it's invalid anyway. Actually the C++ object for the local search operator is not even created.It feels weird to have equivalent models (with or without
max_tasks
) resulting in significantly different computing times for the exact same solution. It's also not satisfactory to require users to provide additional constraints for a reason that is tightly coupled with the internal solving process, not to mention that coming up with the right limits may not always be trivial in the first place.So we should setup a way to derive those implicit constraints automatically and lower max tasks values accordingly for vehicles. Also, this is a great opportunity to speed up things for instances that naturally contain strong implicit constraints.
The text was updated successfully, but these errors were encountered: