dparo/master-thesis

CPTP as BaPCod plugin

dparo opened this issue · 0 comments

dparo commented

TODO

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.