I know about Dijkstra's agorithm, Floyd-Warshall algorithm and Bellman-Ford algorithm for finding the cheepest paths between 2 vertices in graphs.
But when all the edges have the same cost, the cheapest path is the path with minimal number of edges? Am I right? There is no reason to implement Dijkstra or Floyd-Warshall, the best algorithm is Breadth-First search from source, until we reach the target? In the worst case, you will have to traverse all the vertices, so the complexity is O(V)? There is no better solution? Am I right?
But there are tons of articles on the internet, which talk about shortest paths in grids with obstacles and they mention Dijkstra or A*. Even on StackOverfow - Algorithm to find the shortest path, with obstacles
or here http://qiao.github.io/PathFinding.js/visual/
So, are all those people stupid? Or am I stupid? Why do they recommend so complicated things like Dijkstra to beginners, who just want to move their enemies to the main character in a regular grid? It is like when someone asks how to find the minimum number in a list, and you recommend him to implement heap sort and then take the first element from sorted array.
BFS (Breadth-first search) is just a way of travelling a graph. It's goal is to visit all the vertices. That's all. Another way of travelling the graph can be for example DFS.
Dijkstra is an algorithm, which goal is to find the shortest path from given vertex v to all other vertices.
Dijkstra is not so complicated, even for beginners. It travels the graph, using BFS + doing something more. This something more is storing and updating the information about the shortest path to the currently visited vertex.
If you want to find shortest path between 2 vertices v and q, you can do that with a little modification of Dijkstra. Just stop when you reach the vertex q.
The last algorithm - A* is somewhat the most clever (and probably the most difficult). It uses a heuristic, a magic fairy, which advises you where to go. If you have a good heuristic function, this algorithm outperforms BFS and Dijkstra. A* can be seen as an extension of Dijktra's algorithm (heuristic function is an extension).
But when all the edges have the same cost, the cheapest path is the
path with minimal number of edges? Am I right?
Right.
There is no reason to implement Dijkstra or Floyd-Warshall, the best
algorithm is Breadth-First search? Am I right?
When it comes to such a simple case where all edges have the same weight - you can use whatever method you like, everything will work. However, A* with good heuristic should be faster then BFS and Dijkstra. In the simulation you mentioned, you can observe that.
So, are all those people stupid? Or am I stupid? Why do they recommend so complicated things like Dijkstra to beginners, who just want to move their enemies to the main character in a regular grid?
They have a different problem, which changes the solution. Read the problem description very carefully:
(...) The catch being any point (excluding A and B) can have an
obstacle obstructing the path, and thus must be detoured.
Enemies can have obstacles on the way to the main character. So, for example A* is a good choice in such case.
BFS is like a "brute-force" to find the shortest path in an unweighted graph. Dijkstra's is like a "brute-force" for weighted graphs. If you were to use Dijkstra's on an unweighted graph, it would be exactly equivalent to BFS.
So, Dijkstra's can be considered an extension of BFS. It is not really a "complicated" algorithm; it's only slightly more complex than BFS.
A* is an extension to Dijkstra's that uses a heuristic to speed up the pathfinding.
But when all the edges have the same cost, the cheapest path is the path with minimal number of edges?. Yes
If you really understood the post that you linked, you would have noticed that the problem they want to solve is different than yours.
Related
I am trying to implement Branch and Bound approach to the edit distance algorithm. I can't find any hints over internet to start with. Can anyone help me to get into the track of the algorithm.
My apologies for posting this as an answer, I wanted to add it as just a comment, but I don't have sufficient reputation to add comments.
Try to approach your literature search of this subject rather in the context of the graph similarity problem than for the edit distance algorithm; the prior is a more general and well-studied problem which the problem of finding the minimum edit distance fall under. The strings in any instance of your edit distance problem can be described as simple directional graphs, and the operations of insertion/deletion and substitution in the edit distance algorithm has similar operations in the graph similarity problem (e.g., insertion of vertices and edges/deletion of vertices and edges/changing labels on edges and so on).
I'm now working on my undergraduate thesis about shortest path in Netlogo using Dijkstra algorithm
How nw extensions can be implemented in Dijkstra Algorithm coding?
Thank you. .
Not sure I understand your question, but the NW extension uses Dijsktra's algorithm to do its shortest path calculations. The algorithm has been modified so as to save as much information as possible while running. You can read more about that here: https://github.com/NetLogo/NW-Extension#performance
If you're asking about using NW in order to write your own implementation of Dijkstra's algorithm, NW doesn't really help you. It already has Dijkstra's built-in! You can implement Dijkstra's in NetLogo since all you really need is a way to get the links connected to a node and a data structure to store them in that makes it easy to grab the shortest one, called a heap. The connected link calculation is easy (just my-links or link-neighbors; other-end is useful too). The heap is harder. NetLogo doesn't have a built-in heap, nor a good way of creating your own data structures, but you can build heaps just out of lists. You can also just use a list that remains sorted the whole time, but that will hurt the computational complexity.
If all edges had the same weight in a given graph, will Dijkstra's algorithm still find the shortest path between 2 vertices?
Thanks!
Yes dijkstra algorithm can find the shortest path even when all edges have the same weight. dijkstra has time complexity O((V+E)logV).Instead you should choose BFS algorithm to do the same thing,because BFS has time complexity O(V+E),so BFS is asymptotically faster than dijkstra.
Yes it would, But you might want to take a look at Breadth-first search, wich solves the case you are refering to.
To find the path, you can make a recursive function that starts in the destiny node with flagged distance n, and moves to one of the neightbour nodes with flagged distance n-1
i know about the traveling salesman problem, but is there any other algorithm/problem which better fits my needs/description? I need to describe my problem with the help of such a mathematical description.
I have a set of nodes with known start- and endpoint. So i just need to calculate the shortest way to visit all the three points between that two. Dijkstra and similar algorithms try to find the shortest path between two points, so here they probably won´t visit all points between. Or is there a algorithm which finds shortest way and visit all points between two points?
You can achieve it using Ant colony optimization algorithms. Refer Ant colony optimization algorithms.
The complexity of the general case of your problem is at least as high as for the Travelling Salesman problem. Just imagine the case where your two endpoints are basically in the same position, then your problem becomes equivalent to the Travelling Salesman.
If you never expect more than five points in your graph though, do you really need to bother with fancy algorithms? You could just do an exhaustive search for the best solution. Since the only decision is the order in which you visit the three points in the middle, you will only have to test 3! = 6 different paths. Even if I misunderstand you and you want the overall shortest open path that visits all nodes, that would still only be 5! = 120 different paths to test (60 if distances are the same in both directions).
I need to program an algorithm to navigate a robot through a "maze" (a rectangular grid with a starting point, a goal, empty spaces and uncrossable spaces or "walls"). It can move in any cardinal direction (N, NW, W, SW, S, SE, E, NE) with constant cost per move.
The problem is that the robot doesn't "know" the layout of the map. It can only view it's 8 surrounding spaces and store them (it memorizes the surrounding tiles of every space it visits). The only other input is the cardinal direction in which the goal is on every move.
Is there any researched algorithm that I could implement to solve this problem? The typical ones like Dijkstra's or A* aren't trivialy adapted to the task, as I can't go back to revisit previous nodes in the graph without cost (retracing the steps of the robot to go to a better path would cost the moves again), and can't think of a way to make a reasonable heuristic for A*.
I probably could come up with something reasonable, but I just wanted to know if this was an already solved problem, and I need not reinvent the wheel :P
Thanks for any tips!
The problem isn't solved, but like with many planning problems, there is a large amount of research already available.
Most of the work in this area is based on the original work of R. E. Korf in the paper "Real-time heuristic search". That paper seems to be paywalled, but the preliminary results from the paper, along with a discussion of the Real-Time A* algorithm are still available.
The best recent publications on discrete planning with hidden state (path-finding with partial knowledge of the graph) are by Sven Koenig. This includes the significant work on the Learning Real-Time A* algorithm.
Koenig's work also includes some demonstrations of a range of algorithms on theoretical experiments that are far more challenging that anything that would be likely to occur in a simulation. See in particular "Easy and Hard Testbeds for Real-Time Search Algorithms" by Koenig and Simmons.