1111111111
1111110101
1100010101
1111011101
1001010001
1111010101
1100010101
1111011101
1001000001
1111111111
1=Wall
0=Path
Hello i am wondering if i need to add into my adjacency list, wall nodes if i can determine whether a node is a wall through its property, Because since from my knowledge walls will not be considered in calculating the cost for finding a shortest path from a source to a target, for example using A* algorithm.
also Assuming i have a lists of Node objects and each node object contains a list of adjacent nodes, do i need to store adjacent wall nodes?
Well, it is hard to say anything for sure without knowing more details, but for most of the shortest path search algorithms it is fine not to create any nodes for cells that contain a wall at all.
Related
I have a grid map and I need to find the shortest path between two nodes but that path must include some nodes.
I have thought of trying all permutations, but the map size and the number of must nodes will be variable so I would like to use an optimal algorithm.
The map will be something similar to this:
map
-Dark brown square at Y18 is the start point
-Light brown squares from B20 to S20 are the end point (can make just one end point if needed)
-White squares are walls (you cannot go through them)
-Blue squares means that the point in front of it is a must-pass (for example, the blue square at q5-q6 means must pass zone of p5-p6)
I am going to use Java, and I will make that map a graph with connections between them (for example s10 is connected with s9, o10 and s11).
Thank you very much for your help, and if you have any questions just ask.
To my understanding, this is a combination of two problems; you have the stating point, the destination node and the mandatory intermediate nodes. For determination of the shortest path, you would have to calculate the distance between the starting node and all intermediate nodes, all pairs of intermediate nodes, and the distance from each intermediate node to the destination. If only nonnegative edge weights are involved, this can be done with the algorithm by Dijkstra.
Once all distances are calculated, the optimal Hamiltonian path from the starting node to the destination node, where all intermediate nodes are used, has to be calculated. However, as this problem is NP-hard, it most probably cannot be solved using an efficient algorithm; brute-forcing of all permutations might be feasible.
Asymptotically probably this won't help as you still have to solve Hamilton path, but to calculate distances between every node you can use Floyd-Warshall instead to speed things up a little bit.
I am currently working on a project that requires us to help a character find an object within a maze, which is run through a GUI.
However, we can only access the nodes neighboring the location that the character is at, so we are unable to pre-process the maze and build the shortest path before moving the character.
We are given a helper method that returns the number of rows + cols (disregarding the walls that block the way) that each of the neighboring nodes are from this object we are looking for, so I have implemented a DFS and included a min-heap to first traverse the path with the neighbor that has the lowest distance.
Our problem is that sometimes, the path with the lowest distance may reach a dead-end, and we have to wait for it to complete an entire DFS of that branch until it can go back and search another path. Is there an algorithm that could circumvent this problem and reach the object in fewer steps?
Recently I met a coding problem that asks you on a given graph to find out how many different "closed" sub-graphs there are. And after you have found that out you need to search each sub-graph and find how many element are there in each sub-graph. So now to define sub-graph. Let's say we're given
.#####.
#.....#
#.E##.#
#.#.#.#
#.#####
#E..#E#
.#####.
Think of it like a maze where dots represents moving space, while the hashtags are walls and you can move horizontally or vertically. So let's say you are at one point in the graph. All the points you can reach by moving horizontally or vertically are part of a that particular "closed" sub-graph. So for the given example we have 3 "closed" sub-graphs
1#####1
#11111#
#11##1#
#1#2#1#
#1#####
#111#3#
1#####3
Also there are 2 elements in the first sub-graph, no elements in the second and one in the 3rd.
I guess it really doesn't matter what searching method you use, so I used BFS starting from the first entered dot in the line. So once I've reach all possible points starting from that particular point I have found one sub-graph and I have counted how many elements there are in the sub-graph. But the problem now is how to find the starting point of the next sub-graph. I can not think of another way than iterating through the graph until you find a non-visited point and the apply the BFS repeateadly until you have visited all the points. But this method proves to be too much time-consuming, so is there any way I can efficiently find the sub-graphs? For example is there a way to stack at least a point from each sub-graph in a queue, while you're entering the line?
Instead of iterating through the entire graph to find non-visited points you could try iterating though just the walls adjacent to your known sub-groups and look for non-visited points adjacent to those walls. You would be able to compile the list of walls during the bfs.
You can first iterate the graph and find all possible "starting point", hold these elements in a set data structure, and when you do a BFS - for each point you find - remove it from the set of entry points.
Now, at each iteration - all you have to do is choose a random entry point from the set (which is guaranteed to be unvisited yet), and do a new BFS.
I am working on a mapping application that finds the shortest route between the things a user wants. Each thing the user wants (such as bread or gas) has multiple possible locations. Currently, I am simply planning the route between the user and the closest instance of each item to the user, however; this is not always the best route. As outlined in the diagram below, the fastest route sometimes involves visiting clusters of further away node:
For each item, I have up to fifty possible nodes (locations). How can I plan the shortest route that visits every node (in any order)? While pointers to specific examples of how to solve this would be great, all I'm really looking for is a point in the right direction to begin solving this problem.
A solution to this problem can be found by introducing a new graph G':
the nodes in G' are simple paths through the original graph
an edge exists between two nodes when they correspond to partial paths p and p' s.t. p can be extended into p' by adding a node to it.
In this graph (which is huge, so don't explicitly represent it in memory), your desired tour can be found using something like A* search.
You might want to check out chapter 3 of this dissertation for an overview of techniques for solving the vehicle routing problem.
To start out, I would assign a weight to each node based on its distance to the next nearest resource nodes, for example a Gas node that's distance 5 from a Bread node and distance 8 from a Walmart node would have a weight of 13; now go to the Gas node with the lowest weight + distance-from-current-position.
The problem with this heuristic is that it doesn't take into account the distance between the Bread and Walmart nodes - they could be right next to each other, or they could be up to distance 13 from each other. An alternate heuristic is to find the centroid of the subgraph formed by the Gas-Bread-Walmart triangle (or square or pentagon etc depending on how many types of locations you need to visit), add up the distances from the centroid to the points in the subgraph, and use that as the vertex weight.
Small number of items
If your number of items is small you can solve it by using Djikstra on a new graph.
Make a node for each combination of location and which items you have collected.
Use Djikstra to find the shortest route from your start to any node with all items collected.
For L locations and N items, there would be L*2^(N-1) of these new nodes so this is only practical for small N.
Large number of items
I found that ant colony optimisation gave very good results for a similar problem I looked at recently, so this may also be worth a look.
I have an graph with the following attributes:
Undirected
Not weighted
Each vertex has a minimum of 2 and maximum of 6 edges connected to it.
Vertex count will be < 100
Graph is static and no vertices/edges can be added/removed or edited.
I'm looking for paths between a random subset of the vertices (at least 2). The paths should simple paths that only go through any vertex once.
My end goal is to have a set of routes so that you can start at one of the subset vertices and reach any of the other subset vertices. Its not necessary to pass through all the subset nodes when following a route.
All of the algorithms I've found (Dijkstra,Depth first search etc.) seem to be dealing with paths between two vertices and shortest paths.
Is there a known algorithm that will give me all the paths (I suppose these are subgraphs) that connect these subset of vertices?
edit:
I've created a (warning! programmer art) animated gif to illustrate what i'm trying to achieve: http://imgur.com/mGVlX.gif
There are two stages pre-process and runtime.
pre-process
I have a graph and a subset of the vertices (blue nodes)
I generate all the possible routes that connect all the blue nodes
runtime
I can start at any blue node select any of the generated routes and travel along it to reach my destination blue node.
So my task is more about creating all of the subgraphs (routes) that connect all blue nodes, rather than creating a path from A->B.
There are so many ways to approach this and in order not confuse things, here's a separate answer that's addressing the description of your core problem:
Finding ALL possible subgraphs that connect your blue vertices is probably overkill if you're only going to use one at a time anyway. I would rather use an algorithm that finds a single one, but randomly (so not any shortest path algorithm or such, since it will always be the same).
If you want to save one of these subgraphs, you simply have to save the seed you used for the random number generator and you'll be able to produce the same subgraph again.
Also, if you really want to find a bunch of subgraphs, a randomized algorithm is still a good choice since you can run it several times with different seeds.
The only real downside is that you will never know if you've found every single one of the possible subgraphs, but it doesn't really sound like that's a requirement for your application.
So, on to the algorithm: Depending on the properties of your graph(s), the optimal algorithm might vary, but you could always start of with a simple random walk, starting from one blue node, walking to another blue one (while making sure you're not walking in your own old footsteps). Then choose a random node on that path and start walking to the next blue from there, and so on.
For certain graphs, this has very bad worst-case complexity but might suffice for your case. There are of course more intelligent ways to find random paths, but I'd start out easy and see if it's good enough. As they say, premature optimization is evil ;)
A simple breadth-first search will give you the shortest paths from one source vertex to all other vertices. So you can perform a BFS starting from each vertex in the subset you're interested in, to get the distances to all other vertices.
Note that in some places, BFS will be described as giving the path between a pair of vertices, but this is not necessary: You can keep running it until it has visited all nodes in the graph.
This algorithm is similar to Johnson's algorithm, but greatly simplified thanks to the fact that your graph is unweighted.
Time complexity: Since there is a constant number of edges per vertex, each BFS will take O(n), and the total will take O(kn), where n is the number of vertices and k is the size of the subset. As a comparison, the Floyd-Warshall algorithm will take O(n^3).
What you're searching for is (if I understand it correctly) not really all paths, but rather all spanning trees. Read the wikipedia article about spanning trees here to determine if those are what you're looking for. If it is, there is a paper you would probably want to read:
Gabow, Harold N.; Myers, Eugene W. (1978). "Finding All Spanning Trees of Directed and Undirected Graphs". SIAM J. Comput. 7 (280).