I need an algorithm to find ANY path from point A to point B in a graph.
The problem is that finding out wich nodes can follow a specific one needs a quite lengthy matlab simulation, so i want to access as few nodes as possible.
I know some heuristics about the graph, I.E. every node has some coordinates and follow-up nodes are always "near" the previous one, but there is not always a connection between two close nodes.
I am not searching for an optimal path, or even a short one. I just need any connection.
My first try was some simple greedy algorithm that always picks a follow up node closest to the final node, but this ended in dead ends very often. This wouldn't be a problem, but i have no idea how to efficiently move out of a deadend, currently i simply move through all nodes inside the dead end until i find a better way.
Here is a drawing of an example where i already know the solution:
There are many nodes, so calculating the edges for every node in this small dead end on the top takes about 1h20min. (You can assume every pixel in the picture is a node.)
To put it in short words: how do i find a good way around the obstacle without looking at every node inside a whole area.
Sorry if this a silly question but i'm an engineer and never had a formal education in programming aside from making a LED blink.
Thanks in advance!
Related
Since this distance learning thing started I've really struggled to understand data structures and this question really threw me for a loop. I have absolutely no idea how to even start with the code let alone get my point across. Any help at all would be much appreciated...
Pick any node in the graph. That node belongs to some component, and it’s there with potentially a few other nodes. So run a BFS, painting that node and everything reachable from it gold. That’s one component.
Now pick another node. One of two things must be true about it. First, it could be the case that the node has already been painted gold. In that case, you already have counted the component that contains it. Second, it could be unpainted. In that case, you haven’t counted its component, so paint it and all nodes reachable from it gold, and that’s your second component.
Do you think you can generalize this idea so that you count all the components?
As for runtime - how many times does each node get visited this way? Remember that you only paint each node gold once and that each edge is only visited in the course or painting nodes.
You've just input a destination address into your navigation software on your phone. It calculates what it believes to be the route that will take the shortest amount of time.
As you are driving you experience some GPS drift and the navigation software thinks you've taken the offramp on the freeway.
I am wondering from an algorithm perspective, how does the navigation software know to correct itself when it estimates a more accurate location a second later? This question may seem simple, but I am looking for a pretty specific answer.
I am guessing that the application has a graph stored in memory of several nodes which depict different road locations (this is also so that it knows how to plot a line in the right direction). When it guesses you exited at the offramp, it realizes your estimated distance from the node it thinks you went to is too far to be accurate, so it backtracks on the graph and goes the other way and finds the correct node. Is this correct? Or is it much simpler? Does it do a DFS back until it finds the node closest to your current position?
There's very many different navigation systems out there, and they use different algorithms, so I doubt there can be a general answer, but:
What is typically the "textbook" approach to fast navigation is a two-sided slightly modified Dijkstra. In other words, you start from your beginning, and mark all directly connected nodes with the time it'll take you to get there and the node you came from.
Then you repeat that with the nodes connected to these nodes. Rinse, repeat. If you encounter a node that has been seen before, you compare the time your "new" path takes to get there with the one already marked there. Only the shorter one survives.
You do that, alternatingly, from both your start and your destination. (You can be a bit smart – for example, you'll rarely go 50km on back roads in the wrong direction). At some point, both trees "meet". You can basically make a graph cut among all the nodes that you find can be reached from both ends, and use that path that goes through the node of the shortest distance.
Now, back to your problem: Your navigation system finds you've taken a road it didn't expect you to take. No problem, that node can only be one that is directly connected to the node it though you were at – other nodes are unlikely, unless you can teleport. Now, since Dijkstra, as explained above, has already calculated how long it takes to get to that node, it's just a matter of pivoting the tree. Really, pretty standard tactic if you're doing route planning.
So, you have interesting questions! I recommend that, if you haven't, you read about Dijkstra's algorithm.
this is a problem I've got from my class (I assure you it's not homework). I'm still pondering about it until now. You will receive a graph with at most 25 nodes and 25 edges. Additionally, each node will have degree of at most 3. The task is to find the longest path in this graph. However, you won't only receive 1 graph, but 15,000 graphs, and you'll need to find the longest path in all of them in 1 second. Could anyone please give me a solution (or better yet, just a hint) to this problem? Thank you very much!
Info:- Nodes can be revisited, the only constraints are the edges.- The graphs are given by the edges. So the first line states how many nodes and edges there are, and the lines after that represent the edges, each edge by a pair of integers.- The edges are unweighted.- The only answer required is the length of the path, not the path itself.- This might be important: the graph isn't necessarily connected.
After I saw that "nodes can be revisited", I realised that this is in some ways a trick question. To satisfy those seemingly unbelievable time constraints, what you actually need here is not an algorithm for constructing such a path (usually called a trail, BTW, if vertices can be reused), but rather, for each connected component of the graph, a way of quickly detecting whether all or nearly all edges in that component can be included in a single trail.
So here is my hint: Did you know that there are seven bridges in Königsberg? ;-)
That might seem cryptic, but I think some quick searching around will point you in the right direction, and you will soon find a way to quickly detect whether all edges in a component can form part of the same trail. (You'll need to do some more thinking to figure out how many edges can be included when the answer to the above question is "no".)
I am working on a project for shortest path finding. I have looked at alot of resources online to come up with a good algorithm.
I am working with openstreetmap data and it's clear to me that I have to use A* algorithm.
While looking for different solutions, I have found that because a way is made of different nodes, one can prune away the intermediate nodes that are not junctions.
How can I do this in a programming language? If anyone has an idea or a further article that can help me, that would be really grateful.
The exact information I found about this pruning that's relevant to osm is this
parse all ways a second time; a way will normally become one edge,
but if any nodes apart from the first and the last have a link counter
greater than one, then split the way into two edges at that point.
Nodes with a link counter of one and which are neither first nor last
can be thrown away unless you need to compute the length of the edge.
Have a look into the GraphHopper project (where I'm the author of) or other routing projects for OSM already doing this. The idea is to count the number of ways one node is member of and mark nodes as junctions if they have a count of three or more (or just one if an endstanding 'junction').
Still the nodes in-between should be accessible as you need to plot the route for the end results after calculating the route. In GraphHopper we call them pillar nodes (nodes between junctions) and tower nodes (junctions). Here is more detailed information.
Another problem is that you have to calculate GPS precise routes and not just routes from junction to junction. Look into this change how we fixed this via virtual nodes and edges.
I am attempting to write (or expand on an existing) graph search algorithm that will let me find the path to get closest to destination node considering there is no guarantee that the nodes will be connected.
To provide a realistic application of this, let's say I need to get from Brampton, Ontario to Hamilton, Ontario. I know my possible options at my start point are Local transit, GO bus or Walking. I know that walking is the least desired way to get to my destination so I look at GO bus first. I know I can take GO to a point close to Hamilton, but at that point the GO bus turns and goes another direction at that closest point is at a place where I have no options (other than walk, but the algorithm would only consider walking for short distances otherwise it will consider the route not feasible)
Using this same example, if the algorithm were to find that I can get there a way that is longer but gets me closer to the destination node (or possible at the destination node) that would be a higher weighted path (The weightings don't matter so much while its searching, only when the results are delivered, it would list by which path was closest to the destination in ascending order). For example, one GO Bus may get me 3km from the destination node, while 3 public transit buses would get me 500m away
So my question is two fold:
1) What algorithm should I start with that does something similar
2) How would I programmaticly explain that it's ok if nodes don't connect so that it doesn't just jump from node A to node R. Would starting from the end and working backward accomplish this
Edit: I forgot to ask how to aim for the best approximate solution because especially with a large graph there will be possibly millions of solutions for this problem.
Thanks,
Michael
Read up on the A* algorithm. It is a generalization of Dijkstra's shortest path algorithm, that allows you to specify a heuristic, which provides a lower bound for distances between two verteces. In your case, the heuristic function would simply return the Euclidean distance.
Run the algorithm and keep track of the vertex with the best characteristic value, which you somehow compute from the graph distance from source and Euclidean distance to target. The only tricky part is to determine when to terminate (unless you want to traverse the entire graph).
Why can't you assume that all nodes are connected? In the real world, they normally are, i.e. you can always walk or call a taxi, etc.?
In this case, you could simply change your model the following way: You have one graph for each transportation method. The nodes that are at the same place are connected with edges of weight 0 (i.e. if you are dropped off by car at an airport or train station).
Then, label each vertex and edge with the transportation type and you can simply use existing routing algorithms. Oh, by the way: A* will not scale well to really big networks. To get something that software like Yahoo/Google/Microsoft Maps actually would use, have a look here. The work of this research group includes the winner of the DIMACS shortest path challenge.
Sounds very much like a travelling salesman problem with additional node characteristics. Just be wary that this type of problem is NP Complete and your best bet would be to go with some sort of approximation algorithm.