Distance Matrix Rounding about vrplib HOT 4 CLOSED

I can't say whether the values are incorrect, but it may well be. The best bet is to contact the maintainers of CVRPLIB or to check the references about these data.

from vrplib.

Yes, you're right. I appreciate your assistance. Wish you the best with your work.

from vrplib.

Hi @boraaktas!

Thanks for opening this issue. There is nothing wrong with your code and the vrplib package (fortunately!). The differences in the solution cost calculation and the cost provided by the files are due to different rounding conventions that are used in the literature.

As can be seen in output.txt file, the X instances work fine. That's because, in this instance set, the convention is to round the distances to the nearest integer. This can be found back in the associated paper.

However, the CMT, tai, Golden, and Li instance sets don't use this rounding convention. Even though their VRPLIB instance format specifies EUC_2D, whether to round or not is something that is not specified accurately by these instances. To know how to round the distances in these instances, you will have to look into the literature and find the corresponding papers on how they handle this.

This is something I can't do much about because the instances are provided by CVRPLIB, which I'm not the maintainer of. I suggest simply using the X instances, which are currently the benchmark instances for CVRP. Hope this helps.

from vrplib.

Thank you so much for your response, @leonlan. Just as you mentioned, I also noticed that a different approach was used in those sets. However, what puzzled me the most was encountering errors in the instances below:

Solution distance: 1319.0 Optimal distance: 1312 in instance B-n50-k8 *** EUC_2D
Solution distance: 1155.0 Optimal distance: 1153 in instance B-n57-k7 *** EUC_2D
Solution distance: 537.0 Optimal distance: 534 in instance E-n30-k3 *** EUC_2D
Solution distance: 721.0 Optimal distance: 724 in instance F-n45-k4 *** EUC_2D
Solution distance: 1159.0 Optimal distance: 1162 in instance F-n135-k7 *** EUC_2D

It is quite strange that while other instances in these sets provide correct results with rounding to 0 decimals, these cases having errors. Do you think that the values mentioned in the solution files might be incorrect? I don't want to dismiss all other sets based on just a few instances, though! :)

Once again, thank you so much.

from vrplib.