You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The plan mode as described in #430 recently landed in master, replacing the usual solving approach behind Input::solve with a call to the new Input::check function.
As I focused on the implementation feature-wise, I simply re-used the existing matrix available after a request to the routing engine. As a result there are unnecessary calculations performed on the routing side: as task ordering is provided in input for all routes, we could actually get all the information we need by firing one route request per vehicle instead of a request for the whole matrix.
I'm not exactly sure what would be the most elegant way to do this without adding too much boilerplate. A "lazy" approach would be to not change the client code but add a sparse-filling function that would populate only the required entries in the matrix using route requests. A somewhat cleaner approach could be to change the routing Wrapper interface to expose the result of a route request. This response would then be used by the client code in choose_ETA to derive all required durations.
Something else to keep in mind: upon generating the solution, we populate the routes with distance values using the exact same route request, so it should actually be run only once and stored somewhere for reuse.
The text was updated successfully, but these errors were encountered:
The
plan
mode as described in #430 recently landed inmaster
, replacing the usual solving approach behindInput::solve
with a call to the newInput::check
function.As I focused on the implementation feature-wise, I simply re-used the existing matrix available after a request to the routing engine. As a result there are unnecessary calculations performed on the routing side: as task ordering is provided in input for all routes, we could actually get all the information we need by firing one route request per vehicle instead of a request for the whole matrix.
I'm not exactly sure what would be the most elegant way to do this without adding too much boilerplate. A "lazy" approach would be to not change the client code but add a sparse-filling function that would populate only the required entries in the matrix using route requests. A somewhat cleaner approach could be to change the routing
Wrapper
interface to expose the result of a route request. This response would then be used by the client code inchoose_ETA
to derive all required durations.Something else to keep in mind: upon generating the solution, we populate the routes with distance values using the exact same route request, so it should actually be run only once and stored somewhere for reuse.
The text was updated successfully, but these errors were encountered: