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
Is your feature request related to a problem? Please describe.
I'm creating a Unity game as a hobby, and am looking to use this library for pathfinding.
For very large graphs, we want to calculate only the single best shortest path without visiting every vertex for improved performance. (e.g. A-star algorithm)
There are constraints on movement which could be used to limit the search space (optimizing performance) (e.g. Dijkstra's algorithm)
Describe the solution you'd like
Add an option/constructor argument for early termination. If set to True, the priority queue is cleared upon finding the target so that BFS will artificially finish its FlushVisitQueue
Expose the BFS outEdgesFilter to the shortestPath algorithms, so that it can be used to filter the search space based on max cost/vertex distance/whatever the user desires.
Describe alternatives you've considered
Subscribing to the FinishVertex event, canceling the algorithm upon finding the target, and catching the abort exception.
Using FilteredVertexListGraph to limit the search space (but it isn't able to filter dynamically based on cost/distance).
Additional context
I'm not familiar with many of the other shortestPath algorithms, so I don't know if these solutions are applicable beyond Astar and Dijkstras.
The text was updated successfully, but these errors were encountered:
I imagine you're in a case you've specified a root vertex (source) which is then given to the BFS algorithm, and also have implicitly a destination (target) to reach, right?
If yes I imagine that would be something more for an algorithm based on RootedSearchAlgorithmBase<,> which defines a target vertex.
BTW to have the best path to a vertex you may require to explore the full graph which can lead to path reduction (especially with weighted graphs). If we early stop the A* algorithm can we really call it A* then? It would more be a search of the first path to a given vertex regardless of its efficience (best fit). What are your thoughts about that?
Indeed given a vertex the A* will gather the distances to other vertices you're not trying "to go" which is more a side effect of the algorithm because it may be needed to define the path to the real target.
But I would disagree with using RootedSearchAlgorithmBase because early termination is only available for some optimized search algorithms like A*. DFS can't take advantage of it without accepting suboptimal paths, and it doesn't make a whole lot of sense for Dijkstra's to have early termination.
I would normally expect A* to have early termination without the option of disabling it, since that "goal-oriented heuristic optimization" is the whole purpose of using A*.
With regards to early stopping: as long as your heuristic is a "consistent" heuristic, you'll be guaranteed to find the optimal path with A*. I don't think it would be unreasonable to put the onus of ensuring your heuristic is consistent on the user of the A* algorithm.
Otherwise, the current A* implementation is nearly the same as running Dijkstra's performance-wise.
Is your feature request related to a problem? Please describe.
I'm creating a Unity game as a hobby, and am looking to use this library for pathfinding.
Describe the solution you'd like
True
, the priority queue is cleared upon finding the target so that BFS will artificially finish itsFlushVisitQueue
outEdgesFilter
to the shortestPath algorithms, so that it can be used to filter the search space based on max cost/vertex distance/whatever the user desires.Describe alternatives you've considered
FilteredVertexListGraph
to limit the search space (but it isn't able to filter dynamically based on cost/distance).Additional context
I'm not familiar with many of the other shortestPath algorithms, so I don't know if these solutions are applicable beyond Astar and Dijkstras.
The text was updated successfully, but these errors were encountered: