1

I am using Dijkstra's algorithm to solve for the ideal path. As part of the program the algorithm is called several thousands of times.

More than half the time the paths are impossible and Dijkstra's takes a very long time to figure this out (In a small test, possible paths were solved in a total of 2 seconds whereas impossible paths took a total of 25.)

As a result, I'd like to know if there is a way that I could very efficiently check if it is even possible to find a path between 2 nodes before wasting time with the algorithm. Is there any very efficient way to do this?

Thanks, Dan

Daniel Centore
  • 3,220
  • 1
  • 18
  • 39
  • I do not see any java here.. – Vitaly Apr 13 '13 at 20:31
  • You're likely to find a more targeted community for pathfinding and other common game dev topics here: http://gamedev.stackexchange.com/ - also the way you've posed the question is more of a discussion question, which SO is not built to handle. This is more strict Q/A – jefflunt Apr 13 '13 at 20:32
  • Vitaly - Sorry it was written in Java but I guess there was no reason to include it as I'm just asking for theoretical. I removed the tag. – Daniel Centore Apr 13 '13 at 20:33
  • @normalocity Thanks - I'll repost the question there. – Daniel Centore Apr 13 '13 at 20:33
  • 1
    @normalocity this sounds like a basic algo thing, why not here? – Vitaly Apr 13 '13 at 20:34
  • Yet another resource would be wikipedia which has a pretty comprehensive explanation of it, along with alternate algorithms and alterations to consider. http://en.wikipedia.org/wiki/Dijkstra's_algorithm – jefflunt Apr 13 '13 at 20:34
  • @Vitaly - Just trying to give more options for finding the info requested. Didn't vote to close or anything. – jefflunt Apr 13 '13 at 20:35
  • The rather similar question [AI: Fastest algorithm to find if path exists?](http://stackoverflow.com/q/15508370/395760) worked out just fine here. I don't see the need to post to gamedev.SE unless your problem is actually for a video game, and this affects the problem. –  Apr 13 '13 at 20:35
  • Alright I removed the repost. @delnan - thanks for the link! I did try searching ahead of time but couldn't find anything. – Daniel Centore Apr 13 '13 at 20:41

2 Answers2

1

No Constraints, Single Use

On a graph with no constraints, that the program has never seen before (or even part of before), and won't see again. About the only thing you can do is a breadth-first search or a depth-first search.

You might consider using an incremental depth-first search if memory is an issue.

You might consider launching multiple threads on the graph to look along different branches. You would need to coordinate so they don't repeat work by having a concurrent shared data structure they can all inspect and write to safely. With concurrency, you could have some threads searching from the start to end and others from end to start.

On a graph with cycles, you would want to mark nodes as visited, so as to not perform infinite loops.

Constraints, Single Use

Think about your graph and your objective.

Is the graph dense or sparse?

Are there negative edge weights? negative sum cycles?

Does it follow the Trapezoidal rule?

Is there a Maximum Distance beyond which you don't care if there is a path?

Is the graph acyclic?

Is the graph "simple"?

With some work, you may be able to find an approach that is better than dfs for your graph. Other times, you may be able to structure your graph in a different way that makes dfs faster. Sometimes, the advantage may come from not having to store as much data during the search.

Constraints, Multi-Use

If it is worth it, you might run Floyd-Warshall to solve for the shortest paths between every pair of nodes. The algorithm would take some time, but it might be advantageous when you can just perform a look-up for the shortest path in your critical section.

Rather than pre-solving for the shortest paths, you could pre-solve for the connected components by performing an initial dfs on the graph.

If the graph can change, but not drastically, you might be able to simply modify your pre-calculated results, rather than starting over at the beginning each time.

Last Thoughts

The size and complexity of the graph are important considerations. The best algorithm for small, densely connected graphs is going to be different for large sparse graphs or for trees.

Xantix
  • 3,321
  • 1
  • 14
  • 28
0

Are you running the multiple path-lookups on the same graph? If so, you will need to maintain a set of disjoint contiguous spaces from your graph. This can be done live by:

  1. Maintaining contiguous spaces from every unsuccessful path determination, as the complete closed set from the start node;
  2. Constructing a data structure that enables efficient searching of a contiguous spaces once calculated; and
  3. Determining if the start and goal nodes are in the same known contiguous space, in two different contiguous spaces, or unknown prior to each path determination.

The precise best mechanism for (2) is intimately dependent on the nature of your graph, so I leave that for another question.

Pieter Geerkens
  • 11,775
  • 2
  • 32
  • 52