Support dynamic path decisions within the YenShortestPathsAlgorithm #75
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem description
We have a more complex scenario to find the k shortest path just based on k. k is a fixed number like in a for loop. We want instead continue to search until we have met a certain condition, so like in a while loop.
Example
Let's plan a bike tour including some stops for refreshing.
Let's find some routes:
Using existing k parameter and filter
To find 5 routes, we could set k to 5, but this will likely contains some unwanted routes or even no route at all.
We could now using a k of 100 for example, but this could lead to potential overhead in calculation as we find more routes than necessary. Also 100 is just a guess, it could be also 50 or 500, we just do not know in advance.
The filter at the end is not a problem, but we have to ensure that our found routes pool is big enough to pick the wanted routes.
Change
Provide a new function to YenShortestPathsAlgorithm constructor that inspects each path individually and decides:
The default behavior, in case the method parameter is not provided, would be to accept all paths and continue until k is reached.
Technically it would be enough to just check for search continuation based on the found shortest path and then filter at the end. But allowing the filtering right after finding the path would allow to compare the new path with only the wanted path. Otherwise I might have to do the calculation to filter the path in each iteration to check if my abort condition is met.
Main benefit
We can reduce the path finding iterations to the minimum we actual need to met our preset condition. A fixed k could lead to too less results or too many unnecessary iterations which is bad for the performance.