-
Notifications
You must be signed in to change notification settings - Fork 1
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
Prize-collecting instances #1
Conversation
I don't know what prizes will lead to "good" PCVRP instances. But here's one instance property that you could aim to achieve with some additional thoughts:
|
I think the current instances make sense. They are:
Bulhões, T. et al. (2018). The vehicle routing problem with service level constraints. European Journal of Operational Research, 265(2): 544–558. https://doi.org/10.1016/j.ejor.2017.08.027. Stenger, A. et al. (2013). The prize-collecting vehicle routing problem with single and multiple depots and non-linear cost. EURO Journal on Transportation and Logistics, 2(1–2): 57-87. https://doi.org/10.1007/s13676-013-0022-4. |
This reverts commit ece113c.
I toyed a bit with scaling the prizes, but roughly 1.5 times demand seems to work well enough (and is something we can back up with literature). Such prizes work out to 20-40% of all customers on the C and RC instances, and 10-20% on the R instances. I think that's reasonable. |
We might not need the small PC-CVRP instances if we can benchmark against another, good prize-collecting algorithm on the larger PC-VRPTW instances. |
I have an initial set of BKS for the PC-VRPTW instances that I'll inspect and commit tomorrow. |
I'm going to remove the PC-CVRP instances. They're so small that benchmarking on them is basically useless since the solutions are optimal most of the time, and the PC-VRPTW instances already appear to be good enough for evaluating our prize-collecting work. |
This took a bit of work, but on my end I'm happy with these instances and the initial BKS. @leonlan @wouterkool can you have a look at this thread and let me know what you think? |
I just realized that DIMACS is not “round to 1 decimal” but “truncate on 1st decimal”. I think the DIMACS objective is really confusing because of this detail (which I forget about every time). My suggestion is to change the convention to round the distances to the nearest integer. |
That's a good catch. I've updated the text. Our DIMACS rounding function is OK though, so the BKS presented here are fine (the error is only in the text). |
I've updated this several times with new BKS. Now that PyVRP/PyVRP#213 is merged, I will also merge this since it's already become the default benchmark instance set. |
@leonlan @wouterkool I suggest we take the GH1000 and X instances as a basis, and simply add a new prize section to them. Unsure what reasonable prizes would be.
My thinking now is maybe sample these uniformly from
[min distance, max distance]
? What do you think 'reasonable' prizes would be? I'll have a look for some relevant literature before committing to any one thing, but that'll have to wait until tomorrow.