67 shortest path bounded #98
Conversation
…nd up in the results
Add more test cases
There was a problem hiding this comment.
Thanks for the PR!
I think the introduced changes will cause degrading performance because of the added complexity. Before we could guarantee that once a node was seen, it would never be seen again, but when the lower bound is greater than 1 it might be on a cycle and this guarantee can no longer be given.
Since a user might not always have a lower bound that is greater than 1 I suggest copying these iterativelength and shortestpath implementations to new files, and create UDFs with a slightly altered name (iterativelength_lowerbound and shortestpath_lowerbound would be good I think).
Then in match.cpp we can decide which UDF to call depending on the lower bound.
The goal of your project is to change how shortest path is done anyway, so this might change even more soon :)
This reverts commit eb7678e.
…uckpgq-extension into 67-shortest-path-bounded
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
Update; closing this issue, but will use the techniques used here (two-phase path-finding) to implement correct lower-bound constrained path-finding in another PR which is more up-to-date |
Fixes #67 and #94.
Now bounded length query like:
will look for the shortest path between the source and the destination with a length between 2 and 3.
To disambiguate, the effect of this syntax is consistent with choosing the shortest path between the upper and lower bounds after finding all possible paths between two nodes.