The current state of the codebase is that Cost values default to the Duration values as seen from each vehicle. This is not something we want to rely on since:
- we may want to allow more tuning for costs in the future;
- it's already possible to pass in arbitrarily different costs/durations using custom matrices.
Since #555, the separation of cost and duration is a thing in the codebase, even when values are equal. The problem is that when storing costs and gains (e.g. for local search operators), we're loosing information on durations. This information would be required for example in #273: on top of deciding whether a move is actually interesting, we'd need to assert it's valid for max travel time based on how much duration we're adding or removing.
I think the best way to add this information in an extensible way (looking at you #354) would be to change Cost and Gain to structs holding several metrics. For now we'd need the current Cost and Duration values; additional operators doing the math on both metrics; a comparison operator using only actual cost. The good part would be that we would compute all metrics at once with no need to change the client code for all computations within the heuristics and local search operators.
The current state of the codebase is that
Costvalues default to theDurationvalues as seen from each vehicle. This is not something we want to rely on since:Since #555, the separation of cost and duration is a thing in the codebase, even when values are equal. The problem is that when storing costs and gains (e.g. for local search operators), we're loosing information on durations. This information would be required for example in #273: on top of deciding whether a move is actually interesting, we'd need to assert it's valid for max travel time based on how much duration we're adding or removing.
I think the best way to add this information in an extensible way (looking at you #354) would be to change
CostandGainto structs holding several metrics. For now we'd need the currentCostandDurationvalues; additional operators doing the math on both metrics; a comparison operator using only actual cost. The good part would be that we would compute all metrics at once with no need to change the client code for all computations within the heuristics and local search operators.