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

CPTP as BaPCod plugin #12

Open
dparo opened this issue Jan 4, 2022 · 0 comments
Open

CPTP as BaPCod plugin #12

dparo opened this issue Jan 4, 2022 · 0 comments
Assignees
Labels
long term TODO wontfix This will not be worked on

Comments

@dparo
Copy link
Owner

dparo commented Jan 4, 2022

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.

@dparo dparo added the wontfix This will not be worked on label Jan 4, 2022
@dparo dparo self-assigned this Jan 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
long term TODO wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

1 participant