Here's an interesting problem/riddle a friend asked me recently:
You are painting the lines of a tennis court. You have a machine to paint straight lines, but once it is turned on, you can't stop it until the job is done. Clearly you will need to go over some lines twice. What is the smallest amount of extra paint you have to use, in feet?
The dimensions of a court:
The sum of all lines is 480ft. I happen to know that the answer is 63ft extra (543ft total), but I can't help but wonder what the best algorithm is to solve this.
It seems similar to the traveling salesman problem, where each line on the court is represented by a vertex in a graph and junctions of court-lines translate to edges. (Otherwise, if lines were edges and corners were vertices, it would require a path that goes through all edges, and I don't know of any algorithms for that). Maybe you need to be more clever about how junctions of lines are represented and I have some ideas about that, but nothing has really worked yet.
I think the problem is small enough, though, that it can be brute-force-checked with all paths through the line graph. How would you code that?
An undirected graph has an Eulerian trail if and only if at most two vertices have odd degree, and if all of its vertices with nonzero degree belong to a single connected component. （ Found from http://en.wikipedia.org/wiki/Eulerian_path ）
When we get a non-Eulerian graph, we can change it to an Eulerian by adding edges to the odd degree vertices.
So, this problem is turned to: find the lowest cost to turn the graph to a Eulerian.
The algorithm should be:
list all vertices with odd degree , suggest it is a list_vodd[];
find the shortest edge between the vertices in list_vodd[], get two vertices of the edge: pa, pb;
add an edge between pa,pb ( which means this edge should be paint twice );
delete pa,pb from list_vodd[];
goto 2 until there are only two vertices in list_vodd[].
use any existing algorithm to find out a Eulerian router in the new graph with the added edges.
I'm a little late to the game here, but I came across this when I was trying to find an algorithm to determine the shortest path to hike every trail in a state park. Here's a sketch that explains why the answer is 63
As Richard mentioned, this is a Chinese Postman problem. Since the problem didn't specify that we have to start and end in the same location we can use a semi-eulerian graph, which is why all the nodes have an even number, except the start and end points which share a common edge.
Here is a very nice video that explains how to graph and solve this type of problem.
https://www.youtube.com/watch?v=spaUY8PlyYA
Related
I'm having trouble understanding the general idea behind the MAX-CUT problem. Consider the graph below.
The MAX-CUT asks us to find the cut that maximizes the number of edges that it touches. I can trivially draw this.
I don't get what the problem is? For any graph, it's trivial for me to find the line that crosses all the edges. Am I misunderstanding the problem?
EDIT:
In response to David, here's a picture of my version of MAX-CUT where we end on an ending vertex
The formal definition of MAX-CUT is to find a set of vertices S to maximize the number of edges with exactly one endpoint in S. Graphically, this means drawing a simple closed curve and counting only the number of edges crossed an odd number of times.
you are misunderstanding the problem. The goal is to separate the vertices in a bipartite set, meaning into two groups. As an example, look at the bottom and top left vertices, which you disconnected with your cut. These two vertices must therefore be in a different sets. At the same time both of these vertices are disconnected from the vertex in the middle left. This would mean that this vertex also has to be in a different group, which is impossible.
Cutting the edges means assigning the vertices to opposite groups. But you can't assign all vertices to opposite groups because there are only two groups you can choose from.
Let's say we have a maze, which has a width of W and a height of H. In this maze there are multiple people and multiple towers. The people are the sources (S) and the towers (D) are the destinations. It should be known that we have an omniscient view of the maze. My question is then this:
If I want to find the shortest path between any of the different SD combinations, how do I go about this?
At first, I can think of a naive solution that involves breaking this down into SD different OSOD operations, the problem is that this is quite time-consuming.
The second option would be to break it down into S different OSMD operations. But this I suspect is still too time inefficient for what I'm looking for.
I need an algorithm that can perform the pathfinding in O(WH) time. I've not been able to find anything that gives me the shortest path in O(WH) time and which is MSMD based. Hopefully, someone can point me in the right direction.
Imagine a graph that includes the maze as well as start and end vertexes outside the maze, with an edge from the start vertex to every S, and an edge from every D to the end vertex.
Now breadth-first search (since there are no weights) to find the shortest path from the single start to the single end.
I say 'imagine' that graph, because you don't actually have to build it. This ends up being a simple breadth-first search with minor modifications -- you start with all the S nodes in the root level, and stop when you reach any D.
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 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).
I have directed graph with lot of cycles, probably strongly connected, and I need to get a minimal cycle from it. I mean I need to get cycle, which is the shortest cycle in graph, and every edge is covered at least once.
I have been searching for some algorithm or some theoretical background, but only thing I have found is Chinese postman algorithm. But this solution is not for directed graph.
Can anybody help me? Thanks
Edit>> All edges of that graph have the same cost - for instance 1
Take a look at this paper - Directed Chinese Postman Problem. That is the correct problem classification though (assuming there are no more restrictions).
If you're just reading into theory, take a good read at this page, which is from the Algorithms Design Manual.
Key quote (the second half for the directed version):
The optimal postman tour can be constructed by adding the appropriate edges to the graph G so as to make it Eulerian. Specifically, we find the shortest path between each pair of odd-degree vertices in G. Adding a path between two odd-degree vertices in G turns both of them to even-degree, thus moving us closer to an Eulerian graph. Finding the best set of shortest paths to add to G reduces to identifying a minimum-weight perfect matching in a graph on the odd-degree vertices, where the weight of edge (i,j) is the length of the shortest path from i to j. For directed graphs, this can be solved using bipartite matching, where the vertices are partitioned depending on whether they have more ingoing or outgoing edges. Once the graph is Eulerian, the actual cycle can be extracted in linear time using the procedure described above.
I doubt that it's optimal, but you could do a queue based search assuming the graph is guaranteed to have a cycle. Each queue entry would contain a list of nodes representing paths. When you take an element off the queue, add all possible next steps to the queue, ensuring you are not re-visiting nodes. If the last node is the same as the first node, you've found the minimum cycle.
what you are looking for is called "Eulerian path". You can google it to find enough info, basics are here
And about algorithm, there is an algorithm called Fleury's algorithm, google for it or take a look here
I think it might be worth while just simply writing which vertices are odd and then find which combo of them will lead to the least amount of extra time (if the weights are for times or distances) then the total length will be every edge weight plus the extra. For example, if the odd order vertices are A,B,C,D try AB&CD then AC&BD and so on. (I'm not sure if this is a specifically named method, it just worked for me).
edit: just realised this mostly only works for undirected graphs.
The special case in which the network consists entirely of directed edges can be solved in polynomial time. I think the original paper is Matching, Euler tours and the Chinese postman (1973) - a clear description of the algorithm for the directed graph problem begins on page 115 (page 28 of the pdf):
When all of the edges of a connected graph are directed and the graph
is symmetric, there is a particularly simple and attractive algorithm for
specifying an Euler tour...
The algorithm to find an Euler tour in a directed, symmetric, connected graph G is to first find a spanning arborescence of G. Then, at
any node n, except the root r of the arborescence, specify any order for
the edges directed away from n so long as the edge of the arborescence
is last in the ordering. For the root r, specify any order at all for the
edges directed away from r.
This algorithm was used by van Aardenne-Ehrenfest and de Bruin to
enumerate all Euler tours in a certain directed graph [ 1 ].