Integrate GLKH-Solver #56
Conversation
|
Nice @kledom ! What's the status on this? Should I test this? |
|
Hi @rikba, sorry for the late response. I was on vacation for the last 2 weeks. In general, the implementation works but I need to do some more testing. I'll let you know as soon as it's ready. |
|
@rikba Ready for review! |
| @@ -334,7 +334,7 @@ GraphBase<NodeProperty, EdgeProperty>::getAdjacencyMatrix() const { | |||
| if (edgeExists(edge) && getEdgeCost(edge, &cost)) { | |||
| m[i][j] = doubleToMilliInt(cost); | |||
| } else { | |||
| m[i][j] = std::numeric_limits<int>::max(); | |||
| m[i][j] = std::numeric_limits<int>::max(); // TODO: overflow! | |||
There was a problem hiding this comment.
@rikba You might want to have a look at this line. Setting the weights to std::numeric_limits<int>::max() causes an integer overflow within GLKH. What value should we use instead?
There was a problem hiding this comment.
If I remember correctly std::numeric_limits<int>::max()was used in gkma to note edges in the adjacency matrix that are not traversable. I had a look into the GTSPLIB instances in GLKH-1.0/GTSPLIB and they have different large values there, e.g., 10ftv47.gtsp has 100000000, 4br17.gtsp has 9999, 11ft53.gtsp has 9999999. So maybe it's ok to allocate 9999999 like you do below but add a TODO that we want to setup the problem in EDGE_DATA_FORMAT and let GKLH handle the disconnected edges.
| for (auto w_ij : task.m[i]) | ||
| { | ||
| if (w_ij == 2147483647) | ||
| { | ||
| // TODO: FIX Overflow | ||
| w_ij = 9999999; | ||
| } |
There was a problem hiding this comment.
This is my current hotfix (should be removed before merging).
| @@ -334,7 +334,7 @@ GraphBase<NodeProperty, EdgeProperty>::getAdjacencyMatrix() const { | |||
| if (edgeExists(edge) && getEdgeCost(edge, &cost)) { | |||
| m[i][j] = doubleToMilliInt(cost); | |||
| } else { | |||
| m[i][j] = std::numeric_limits<int>::max(); | |||
| m[i][j] = std::numeric_limits<int>::max(); // TODO: overflow! | |||
There was a problem hiding this comment.
If I remember correctly std::numeric_limits<int>::max()was used in gkma to note edges in the adjacency matrix that are not traversable. I had a look into the GTSPLIB instances in GLKH-1.0/GTSPLIB and they have different large values there, e.g., 10ftv47.gtsp has 100000000, 4br17.gtsp has 9999, 11ft53.gtsp has 9999999. So maybe it's ok to allocate 9999999 like you do below but add a TODO that we want to setup the problem in EDGE_DATA_FORMAT and let GKLH handle the disconnected edges.
|
@rikba I just rebased the commits to the current master. Just in case you are still considering merging this. |
Removes mono dependency by integrating Helsgaun's GLKH-Solver (http://webhotel4.ruc.dk/~keld/research/GLKH/).
Solves #24.