Cycle of maximum weight in a graph - algorithm

Given a weighted graph (directed or undirected) I need to find the cycle of the graph with the maximum weight.
The weight of a cycle being the sum of the weight of the edges of the graph.
It can be any cycle, not just base cycle for which we can
find all base cycle (see Algorithms to Identify All the Cycle Bases in a UnDirected Graph )
compute the weight of each base cycle and find the maximum
I could try to enumerate all cycles of the graph and then compute the maximum but the total number of cycles can be really big (if the graph is complete then any sequence of vertices where the first and last one are identical is a cycle).
Do you have any idea to find that maximum weight cycle without enumerating all cycles ?
If you need hypothesis on the graph (positives weights for example) please indicates them.

This is NP-Hard.
Hamiltonian Cycle problem can be reduced to this.
Given a graph for which we need to check if there exists a Hamiltonian Cycle or not, assign weight 1 to each edge.
Now run your algorithm to get the maximum weight cycle. If the weight is < n, then the original graph has no Hamiltonian cycle, otherwise it does.

If you can find the minimum weighted path in your specific case, just reverse the signs of all the weights and apply your algorithm. Of course you are making some unstated assumptions because Moron's argument is correct (no pun intended). The assumptions you are making could be positive weights or no negative weight cycles. I think you should make an effort to state them instead of letting people search in the infinite space of possible assumptions. As to hardness results, this is also hard to approximate in a number of way, check out this paper. The same paper contains several positive results for important types of graphs, but it's concerned with longest unweighted paths so my guess is that most algorithms in the paper won't directly help in your case. If you search for "Heavy cycles" you will find a number of interesting papers, but they are more mathematical in character. If your weights are small integers (up to a polynomial in the size of the graph), you can try and replace every edge with an unweighted path to reduce your problem to the unweighted case. I hope this helps to some degree, but you might have an open research problem on your hands.

Related

Maximum weighted Hungarian method Using minimum Hungarian method

I have programmed the minimum Hungarian algorithm for a bipartite graph, with Dijkstra's algorithm to find the minimum cost of a maximum matching. However, I want to use such an algorithm to implement the maximum Hungarian algorithm and don't know if it's correct to just negate the edges, because I don't know if the algorithm will handle it.
My implementation is based on the explanation on the following site: https://www.ics.uci.edu/~eppstein/163/lecture6b.pdf
Given G=(AUB, E), the idea is to label the vertices via an artificial start vertex s which has edges with unsaturated nodes in A, and run Dijkstra's algorithm from s in order to label each vertex, then after labeling each, the edges will be reweighted by their original weight minus the labels of the edge's endpoints.
I have read a lot of articles, and the only I could see is that a minimum Hungarian algorithm can be handled well with maximum cost by negating each edge, however, I am afraid that due to the fact that Dijkstra's algorithm doesn't handle negative edges well, it won't work.
First find the maximum weight in your graph. Then negate all of the weights and add the maximum weight to them. Adding the original maximum to all of the negated values makes them all positive.
You can also use INT_MAX (or whatever is equivalent to it in the programming language you're using) instead of the maximum weight. This skips the step of finding the maximum weight, but could make the first iteration of the Hungarian Algorithm take longer, or cause you to need an extra iteration of the algorithm to get the result. It probably doesn't make much of a difference either way and the performance difference will vary based on the particular weights in your graph.

Which of the following statements are true for the given special cases of the Traveling Salesman Problem?

I'm taking the Algorithms: Design and Analysis II class, one of the questions asks:
Which of the following statements is true?
Consider a TSP instance in which every edge cost is either 1 or 2. Then an optimal tour can be computed in polynomial time.
Consider a TSP instance in which every edge cost is negative. The dynamic programming algorithm covered in the video lectures might not
correctly compute the optimal (i.e., minimum sum of edge lengths) tour
of this instance.
Consider a TSP instance in which every edge cost is negative. Deleting a vertex and all of its incident edges cannot increase the
cost of the optimal (i.e., minimum sum of edge lengths) tour.
Consider a TSP instance in which every edge cost is the Euclidean distance between two points in the place (just like in Programming
Assignment #5). Deleting a vertex and all of its incident edges cannot
increase the cost of the optimal (i.e., minimum sum of edge lengths)
tour.
I argue as follows:
The DP algorithm doesn't make any assumptions on the edge costs, so option 2 is incorrect.
If all edge weights are negative, then deleting a vertex and all of its incident edges can certainly increase the minimum sum because in effect, that edge weight is now added to the previous minimum. Thus, option 3 is incorrect.
Take the optimal tour in the original instance. Now, instead of visiting the deleted vertex v, skip straight from v's predecessor to its successor on the tour. Because Euclidean distance satisfies the "Triangle Inequality", this shortcut only decreases the overall distance traveled. The best tour can of course only be better. Thus, option 4 is correct.
However, I'm not able to find any significance for TSP problems with unit edge costs. Is option 1 merely a trick, or is there more to it?
OP here:
Papadimitriou and Yannakakis have shown that it is possible to approximate the TSP problem 1 in polynomial time within accuracy 7/6. This guarantee has been further improved by Bläser and Shankar Ram to 65/56. However, no matter how good those results are, those are still approximations, and not an optimal solution. Thus, option 1 is incorrect.

Can we use Dijkstra in this case?

Given a graph that has negative weights but we know for sure it has no negative cycle:
Add a big enough constant to all weights so they are now positive and use Dijkstra's algorithm to find the smallest path.
Is the above correct if we don't have negative cycles? If we have negative cycles we can't use that algorithm since it will need to revisit the nodes Dijkstra marked as completed.
By adding a constant to all the weights you shall make paths with more number of edges more costly and paths with less number of edges relatively less costly hence disrupting the original problem.
So you can't apply Dijkstra even if there is no negative weight cycle.

Find the lowest-cost shortest path from one node to another?

I have a weighted graph G and a pair of nodes s and t. I want to find, of all the paths from s to t with the fewest number of edges, the one that has the lowest total cost. I'm not sure how to do this. Here are my thoughts:
I am thinking of finding the shortest path and if there are more than one path then i should compare the number of steps of these paths.
I think I can find the number of steps by setting the weights of all edges to 1 and calculate the distance.
A reasonable first guess for a place to start here is Dijkstra's algorithm, which can solve each individual piece of this problem (minimize number of edges, or minimize total length). The challenge is getting it to do both at the same time.
Normally, when talking about shortest paths, we think of paths as having a single cost. However, you could imagine assigning paths two different costs: one cost based purely on the number of edges, and one cost based purely on the weights of those edges. You could then represent the cost of a path as a pair (length, weight), where length is the number of edges in the path and weight is the total weight of all of those edges.
Imagine running Dijkstra's algorithm on a graph with the following modifications. First, instead of tracking a candidate distance to each node in the graph, you track a pair of candidate distances to each node: a candidate length and a candidate weight. Second, whenever you need to fetch the lowest-code node, pick the node that has the shortest length (not weight). If there's a tie between multiple nodes with the same length, break the tie by choosing the one with the lowest weight. (If you've heard about lexicographical orderings, you could consider this as taking the node whose (length, weight) is lexicographically first). Finally, whenever you update a distance by extending a path by one edge, update both the candidate length and the candidate weight to that node. You can show that this process will compute the best path to each node, where "best" means "of all the paths with the minimum number of edges, the one with the lowest cost."
You could alternatively implement the above technique by modifying all the costs of the edges in the graph. Suppose that the maximum-cost edge in the graph has cost U. Then do the following: Add U+1 to all the costs in the graph, then run Dijkstra's algorithm on the result. The net effect of this is that the shortest path in this new graph will be the one that minimizes the number of edges used. Why? Well, every edge adds U+1 to the cost of the path, and U+1 is greater than the cost of any edge in the graph, so if one path is cheaper than another, it either uses at least one fewer edge, or it uses the same number of edges but has cheaper weights. In fact, you can prove that this approach is essentially identical to the one above using pairs of weights - it's a good exercise!
Overall, both of these approaches will run in the same time as a normal Dijkstra's algorithm (O(m + n log n) with a Fibonacci heap, O(m log n) with another type of heap), which is pretty cool!
One node to another would be a shortest-path-algorithm (e.g. Dijkstra).
It depends on your input whether you use a heuristic function to determine the total distance to the goal-node.
If you consider heuristics, you might want to choose A*-search instead. Here you just have to accumulate the weights to each node and add the heuristic value according to it.
If you want to get all paths from any node to any other node, you might consider Kruskal’s or Prim’s algorithm.
Both to basically the same, incl. pruning.

Efficient Algorithm for calculating Edge Connectedness?

What I would like to know is if there is any literature that I could read for algorithms to determine the edge connectedness of all edges in a given graph.
The edge connectedness of a given edge (as understood by me) is the number of shortest paths (between diff nodes) that pass through a given edge. That is, if we were to travel from every node to every other node, how many times would we pass through a given edge.
Any help/resource would be appreciated
This is called edge betweennesss as far as I know. Here is a paper for a good algorithm for vertex betweenness, it can be easily generalized to edge betweenness:
Brandes, Ulrik (2001). "A faster algorithm for betweenness centrality" (PDF). Journal of Mathematical Sociology 25: 163–177
http://www.inf.uni-konstanz.de/algo/publications/b-fabc-01.pdf
Use Dijkstra algortihm to find the shortest path. Use this algorithm repeatedly to determine the shortest paths of all pairs of nodes. Now you can simply sum up the occurence of each edge in each path.

Resources