My research is about find a shortest path between an origin and a destination predefined. Both (origin and destination) were located using the GIS extension, because they were obtained by a shape file. I used the command ask patches gis:intersecting shapefile to create a person in an origin and a school in the destination.
I have 10 origins and for each I have a specify destination. I noticed that when I use the Dijsktra's algorithm to find the shortest path, for certain origin the destination isn't the respective point but the closest destination.
So, my doubt is: Is the Dijsktra's the best algorithm for my problem or I need to use the A* algorithm?
If the Dijsktra's algorithm is the best, how do I inform the pairs origin and destination in the code?
If the A* algorithm is the best, how do I construct the code in the version 5.0 of Netlogo?
Not sure about netlogo, but since your question doesn't quote it in the tags I'll assume an algorithm oriented answer is ok.
Dijkstra and A* are similar; both look and find the shortest path from one point to another. A* is more effective when you've got a known-in-advance destination as it optimally looks for the shortest possible path through the heuristics, while dijkstra exapnds more nodes in your graph by searching all directions.
If you find that Dijkstra returns a path to a different destination than the one you expect, you should consider verifying the destination detection: you should conclude the dijkstra searcg when you find THAT destination, not ANY destination.
A* doesn't suffer so much of the same since the heuristics will point them towards the correct destination, but can in special cases find the same problem (i.e. shortest path to correct destination passes through a different destination).
TO be more precise, I'd need some code - pseudocode is ok - of your conclusion, or details on the graph.
Related
I have multiple gpx files from walking routes which I combined to one big gpx file so it displays a collection of all the routes of a certain area. I want to use the file in MATLAB and perform Dijkstra's shortest path algorithm on it. Can anyone recommend a way to do this?
Should I convert the gpx data in order to make it possible, or are there ways to make these calculations on the data itself?
Recent MATLAB version has functions to read GPX files
https://www.mathworks.com/help/map/ref/gpxread.html
and the File Exchange has few contributions for Dijkstra's Shortest Path Algorithm
Joseph Kirk (2021). Dijkstra's Shortest Path Algorithm https://www.mathworks.com/matlabcentral/fileexchange/12850-dijkstra-s-shortest-path-algorithm and Another here https://www.mathworks.com/matlabcentral/fileexchange/36140-dijkstra-algorithm
I am interested in finding k shortest path from source node to destination node by dijkstra's algorithm. i have solved the same problem with the help of dvar boolean to declear a boolean variables for the link which can take value 1 if the link is selected for path and 0 otherwise but the problem there this variable calculate the shortest path for each flow which is much time consuming. Now i am interested to get rid of flow conservation constraint and use some type of algorithm for column generation approaches which can resolve the problem at once not to calculate the path for each variable. I am looking forward to hearing from you
If you are concerned about performance then it is probably not a good idea to attack this problem with a general integer programming solver. As you can see for example here, there are dedicated algorithms available to solve the k-shortest path problem efficiently.
If you want to stick with OPL then you could implement those algorithms using OPLScript.
I am trying to code Dijkstra algorithm to find the shortest paths between nodes of some electrical cable trays (given as directed graph). My question is; if we have turns (i.e. not a straight path as the company wish to have) how we can handle this problem ?
Dijkstra cannot incorporate a turn-penalty directly, since it is built around the assumption that the cost to reach a node is independent of its "context".
It is possible to rewrite your graph so that every turn is associated with taking an edge, so turn costs become normal costs. Dijkstra can then be applied to that graph. A full explanation can be found in "Modeling Costs of Turns in Route Planning" (Stephan Winter). The graph used for this (line graph) is sometimes called the dual graph, though that term traditionally had a different meaning. Roughly, you introduce a node for every original edge, and an edge between two of the new nodes if the corresponding edges are both adjacent to the same original node (every tiny path of 2 steps is represented by an edge in the new graph). All edges leading out of the source and into the target correspond to separate nodes in the new graph, to avoid turning the problem into multi-source/multi-target shortest path, you may add an additional source node and target node that "tie the edges together" (with zero cost).
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 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.