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
Develop an API to use CPTP as BaPCod pricer plugin, and test the new performance.
WHY
Having CPTP in a separate executable incurs in costs which are unavoidable. For each pricing iteration CPTP needs to: spawn its process, parse command line arguments, setup CPLEX environment, allocate memory, setup MIP model, etc. Also, by living inside the same executable, cut generated at previous iterations can potentially be reused (no wasted work). The performance comparison will always be skewed in favour of BaPCod, even if CPTP manages to do a fantastic job for what it has available.
An iteration-by-iteration comparison is not possible thanks to the fact that BapCod pricer is not guaranteed to generate elementary paths. Even when the NG-path set size is set to a the maximum allowed value, eg 63, the NG-path set size is dynamically lowered/raised only when the RCSP pricer deems it to be important. This means that even at the last pricing iteration, the NG path size is not guaranteed to be equal to the maximum settable value. On top of that, there's no way for client code (eg the BcRCSPFunctor) to know the current value of the NG set size. Therefore elementarity can be guaranteed in BapCod only for instances having less than K <= 63 customers, where K value could be anything. CPTP solves a much harder problem by considering the elementarity constraint. Comparing solution time on a iteration-by-iteration basis is not fair. The much more RELIABLE total solution time, measured as the time BaPCod takes to solve the entire CVRP instance, is the approach that should be taken.
Running as a pricer inside BapCod also allows us to have an absolute performance metric which is RELIABLE (eg total solution time for a CVRP instance). Imagine the following scenario for an example input CVRP instance:
BapCod pricer would need 1000 iterations taking 10 ms each before concluding no reduced cost tour exist
CPTP pricer would need a single iteration taking 0.5 s before concluding no reduced cost tour exist.
Under a iteration-by-iteraion comparison CPTP always loses, but under the big scheme of things, it wins.
The text was updated successfully, but these errors were encountered:
TODO
Develop an API to use CPTP as BaPCod pricer plugin, and test the new performance.
WHY
NG path size
is not guaranteed to be equal to the maximum settable value. On top of that, there's no way for client code (eg theBcRCSPFunctor
) to know the current value of the NG set size. Therefore elementarity can be guaranteed in BapCod only for instances having less thanK <= 63
customers, whereK
value could be anything. CPTP solves a much harder problem by considering the elementarity constraint. Comparing solution time on a iteration-by-iteration basis is not fair. The much more RELIABLE total solution time, measured as the time BaPCod takes to solve the entire CVRP instance, is the approach that should be taken.10 ms
each before concluding no reduced cost tour exist0.5 s
before concluding no reduced cost tour exist.Under a iteration-by-iteraion comparison CPTP always loses, but under the big scheme of things, it wins.
The text was updated successfully, but these errors were encountered: