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
{{ message }}
This repository was archived by the owner on Mar 1, 2021. It is now read-only.
See here. To summarize, finding candidates on the fly (i.e. at each step of the viterbi sequence) would be beneficial as
it's probably cleaner - when first reading the code it's confusing why we first find the candidates, then look them up, then create all the time steps, etc.
less memory (e.g. long routes)
possibly opens some avenues for optimization e.g. where we know we don't need to find any candidates for the point (e.g. if the timestamp is the same as a last one).
means an online viterbi algorithm is possible ...
The main challenge seems to be implementation - we can't call queryGraph.lookup multiple times, and we can't (?) create separate queryGraphs without getting duplicate virtual node IDs. So, we can focus on trying to fix this - or there may be another solution (e.g. if we use edge-based traversal it may change things).
For now, I'm flagging this as an issue, but I suggest we wait until the main algorithm/API stabilises somewhat (e.g. #88 and #87) before we try to find a solution.