While working on #828 I noticed a solving change related to signedness modification. Turns out that this is because we're mixing signed and unsigned values here:
|
auto smallest = _input.get_cost_upper_bound(); |
|
auto second_smallest = _input.get_cost_upper_bound(); |
|
std::size_t smallest_idx = std::numeric_limits<std::size_t>::max(); |
|
|
|
for (std::size_t i = 0; i < routes.size(); ++i) { |
|
if (route_job_insertions[i][j].eval.cost < smallest) { |
|
smallest_idx = i; |
|
second_smallest = smallest; |
|
smallest = route_job_insertions[i][j].eval.cost; |
|
} else if (route_job_insertions[i][j].eval.cost < second_smallest) { |
|
second_smallest = route_job_insertions[i][j].eval.cost; |
|
} |
|
} |
The result of _input.get_cost_upper_bound() is unsigned so it's possible to have an underflow whenever route_job_insertions[i][j].eval.cost (signed value) is negative. Cost insertions should be positive in theory but in reality they may be negative whenever the triangular inequality is broken. This is quite rare but does happens in practice with real-life instances, and also with e.g. Solomon instances due to rounding precision.
There is no risk of crash, or providing a screwed solution, but we're discarding some (good) insertions options there so this piece of code does not always behave as intended.
While working on #828 I noticed a solving change related to signedness modification. Turns out that this is because we're mixing signed and unsigned values here:
vroom/src/algorithms/local_search/local_search.cpp
Lines 194 to 206 in 4b898ec
The result of
_input.get_cost_upper_bound()is unsigned so it's possible to have an underflow wheneverroute_job_insertions[i][j].eval.cost(signed value) is negative. Cost insertions should be positive in theory but in reality they may be negative whenever the triangular inequality is broken. This is quite rare but does happens in practice with real-life instances, and also with e.g. Solomon instances due to rounding precision.There is no risk of crash, or providing a screwed solution, but we're discarding some (good) insertions options there so this piece of code does not always behave as intended.