CVRP heuristic enhancement and tuning

[jcoupey]

Issue

This PR aims at implementing #153 and the CVRP-related part of #166.

Tasks

• Adjust VRPTW heuristic(s) to CVRP case
• See how they perform compared to the existing clustering heuristics
• Adjust tuning with the new options for homogeneous case
• Adjust tuning with the new options for heterogeneous case
• Update CHANGELOG.md
• review

[jcoupey]

v1.2.0 VS this PR

Comparing this PR to the latest release (v1.2.0) yields interesting results for all exploration levels:

• More optimal solutions found
• Overall computing times reduction
• Median and average gaps significantly reduced
• Largely improved worst cases

Also as of exploration level 1:

• More jobs handled
• More instances solved with all jobs

Examples

On the usual CVRP benchmarks.

Exploration level 0 (fastest)

	v1.2.0	PR
Median computing time	49ms	22ms
Longest computing time	4.7s	1.6s
Jobs assigned	99.67%	99.54%
Solutions with all jobs	160 (84.7%)	158 (83.6%)
Best known solutions	5 (2.65%)	13 (6.88%)

For instances with all jobs assigned:

	v1.2.0	PR
Minimum gap	+0.00%	+0.00%
Median gap	+5.07%	+2.87%
Average gap	+5.87%	+3.43%
Worst gap	+23.7%	+19.0%

Exploration level 5 (best)

	v1.2.0	PR
Median computing time	657ms	534ms
Longest computing time	188.7s	99.2s
Jobs assigned	99.86%	99.86%
Solutions with all jobs	169 (89.42%)	171 (90.48%)
Best known solutions	31 (16.40%)	38 (20.11%)

For instances with all jobs assigned:

	v1.2.0	PR
Minimum gap	+0.00%	+0.00%
Median gap	+1.61%	+0.98%
Average gap	+2.36%	+1.78%
Worst gap	+13.6%	+10.45%

[krypt-n]

That's pretty cool.

Solutions with all jobs | 160 (84.7%) | 158 (83.6%)

I noticed this locally too. It should probably be investigated.

[jcoupey]

It should probably be investigated.

The difference in number of jobs for -x 0 is the consequence of a tuning choice and the counterpart of:

Median gap | +5.07% | +2.87%
Average gap | +5.87% | +3.43%

The selection of parameters for v1.2.0 was directed toward including more jobs. This was a bit biased as some parameters only showed up because of their ability to handle more jobs on some very tight special random benchmark instances, regardless of their cost efficiency.
For this PR, I've been tuning for overall cost (with a smaller penalty on unassigned jobs). The good part is that except for level 0, this also means handling more jobs. I decided to keep it that way, considering that:

• most real life instances won't be that tight
• the purpose of -x 0 is to keep an efficient way to scale for huge instances, but I suspect it won't be used that often anyway.

[krypt-n]

You're probably right