Related
I'm looking at several problems of similar format but different difficulty. Help would be appreciated for polynomial (preferably relatively fast, but not necessarily), and even brute-force solutions of any of them.
The idea of all of the problems is that you have a weighted, undirected graph, and that an agent controls some of the nodes of the graph at the start. The agent can gain control of a node if they already control two adjacent nodes. The agent is trying to minimise the time they take to control a certain number of nodes. The problems differ on some details.
(1) You gain control of nodes in order (ie. you cannot take over multiple nodes simultaneously). The time taken to take control of a node is defined as the minimum of the edges from the two nodes used to take control of it. The goal is to take control of every single node in the graph.
(2) Again, you gain nodes in order and the goal is to take control of every single node in the graph. The time taken to take control of a node is defined as the maximum of the two nodes used to take control of it.
(3) Either (1) or (2), but with the goal of taking control of a certain number of nodes, not necessarily all of them.
(4) (3), but you can take control of multiple nodes simultaneously. Basically, say nodes 2 and 4 are being used to take over node 3 in time of 5. During that time of 5, nodes 2 and 4 cannot be used to take over a node that is not node 3. However, nodes 5 and 6 may for example be simultaneously taking over node 1.
(5) (4), but with an unweighted graph.
I started with the problem (4). I progressively made the problem easier from (4) to (3) to (2) to (1) with the hopes I could construct the solution for (4) from that. Finally, I have solved (1) but do not know how to solve any other one. My solution to (1) is this: of all candidate nodes which have two adjacent nodes that we control, simply take the one which takes the shortest amount of time. This is similar to Dijkstra's shortest path algorithm. However, this kind of solution should not solve any of the others. I believe that possibly a dynamic programming solution might work though, but I have no idea how to formulate one. I also have not found brute force solutions for any of the 4 problems. It is also possible that some of the problems are not polynomially solvable, and I would be curious to know why if that is the case.
Idea for the questions are my own, and I'm solving for my own entertainment. But I would not be surprised if it can be found elsewhere.
This isn't an answer to the problem. It is a demonstration that the greedy approach fails for problem 1.
Suppose that we have a graph with 7 nodes. We start by controlling A and B. The cost from A to B and B to C and C to D are all 1. Both E and F connect to A, B, and D with cost 10. G connects to A, B, C, and D with cost 100.
The greedy strategy that you describe will connect to E and F at cost 10 each, then D at cost 10, then C at cost 1, then G at cost 100 for a total cost of 131.
The best strategy is to connect to G at cost 100, then C and D at cost 1, then E and F at cost 10 for a total cost of 122 < 131.
And this example demonstrates that greedy is not always going to produce the right answer.
I haven't been able to come up with a reduction yet, but these problems have the flavor of NP-hard network design and maximum coverage problems, so I would be quite surprised if variants (3) through (5) were tractable.
My practical suggestion would be to apply the Biased Random-Key Genetic Algorithm framework. The linked slide deck covers the generic part (an individual is a map from nodes to numbers; at each step, we rank individuals, retain the top x% "elite" individuals as is, produce y% offspring by crossing a random elite individual with a random non-elite individual, biased toward selecting the elite chromosomes, and fill out the rest of the population with random individuals). The non-generic part is translating an individual into a solution. My recommended starting point would be to choose to explore the lowest-numbered eligible node each time.
This is a follow-up question on my other posts.
Algorithm for clustering with size constraints
I'm working on a clustering algorithm,
After some reclustering, now I have this set of points that none of them are in their optimal cluster but could not be reassigned individually, since it'll violate the constraint.
I'm trying to use a graph structure to solve the problem but came across a few issues in implementing.
I'm a beginner, please let me know if I'm wrong.
Per #Kittsil's answer
build a directed graph with clusters as nodes, such that an edge (A,B) exists if the global solution would be minimized by some point in A moving to B. Looking for cycles in this graph will allow you to find potential moves (where a move consists of moving every vertex in the cycle).
I revised the graph adding weight as the sum of number of points moving from A to B.
Here are some scenarios where I'm not sure how to decide on which point to reassign.
Scenario 1. For a cycle as below. There are two points can be moved from A to B, and three from B to C. Under this situation, which point should I select to reassign?
Scenario 2. For a cycle as below. Let all edge weights be 1. For the point in cluster A, it could be reassign to either cluster B or D. In this case. How should I do the reassignment?
Scenario 3 Similar to Scenario 2. Let all edge weights be 1. There are two small cycles in the bigger cycle. The point in cluster A can be reassigned to both B and E, how do I decide on the reassignment in this case?
Ideas about either scenario is welcomed!
Also any suggestions on implementing the algorithm considering the cases above? Even better with pseudocode. Thanks!
If the edge weights are proportional to the benefit gained by reclustering the points, then a decent heuristic is to pick the cycle with the highest total weight. I think this addresses all three of your cases: whenever you have a choice, pick the one that will do the most good.
Discussion:
The algorithm described in Algorithm for clustering with size constraints is a greedy algorithm to find a local minimum. Therefore, there is no guarantee that you will find the best solution no matter how you choose in these scenarios, and any choice will drive you closer to the local minimum.
Due to the relation to similar problems of sorting with constraints, it is my intuition that the minimum problem is going to be NP-hard. If that is not the case, then there exists a much better algorithm than the one I previously described. However, this greedy algorithm seems like a fast solution for the minimal problem.
I have to study the resistance of the principal cluster of a percolating network of conducting wires
. Individual wires are labeled from 1 to n. I represent the network by a graph G(V,E) and find its adjacency matrix A, where A_ij = 1 if wires i and j are in contact, 0 otherwise.
My question is the following : given that I need to implement Kirchhoff's Laws
on the main percolated cluster, I need an algorithm that returns all the, ideally, smallest loops in the cluster. Do you know of an algorithm (mine is bruteforce now and not efficient) that finds all the loops inside a graph from its adjacency matrix ?
In general, there can be exponentially many simple cycles (loops), so since you want only the "smallest", it sounds as though you don't want them all. If you're looking to write equations corresponding to Kirchhoff's second law for all possible cycles, then it suffices to use just the equation for each cycle in a cycle basis. There is a polynomial-time algorithm to find the cycle basis that uses the least total number of edges (minimum cycle basis). Rather than implement that algorithm, however, it may suffice to switch from arc variables xu→v to differences of node variables yv - yu (fix one node variable per connected component to be zero).
I want to do something similar to Appointment scheduling algorithm (N people with N free-busy slots, constraint-satisfaction). But my additional requirement is that I should be able to give 2nd optimal solution, 3rd optimal solution and so on.
Is it possible to achieve this without hitting the performance badly?
There isn't a lot of research (to my knowledge) into finding the solutions, in order, from the most optimal, as most of the time we just care about finding an as efficient as possible solution. So, on the assumption that a better solution might not come to light, I'll give this solution.
To find the most efficient solution, use the accepted answer in the linked question. Copied here for convenience:
Find a maximum matching in a bipartite graph (one set of vertices is the set of people and the other on the set of slots, there is an edge between a person and a slot if the person is available for this slot).
This problem can be solved with the Hopcroft-Karp algorithm.
Complexity O(n5/2) in the worst case, better if the graph is sparse.
Now, in turn, try to remove each edge of the output from the input graph and run the algorithm again.
One of these runs should give you the second-most optimal.
Now, in turn, try to remove each edge of the output from the graph that gave you the second-most optimal and run the algorithm again.
Now the third-most optimal should be among the generated sets.
Now similarly try to remove the edges of the graph of the third-most optimal.
And so on.
Complexity:
O(n5/2) in the worst case for the optimal solution.
O(n7/2) (O(n.n5/2)) in the worst case for each next solution to be generated.
Example:
Say you have edges a,b,c,d,e,f,g.
Let's say the maximum match is a,b,c.
Now you remove a from the input graph and get b,c,d,e,f,g.
Let's say the maximum match of this graph is c,d,e.
Now you remove b from the input graph and get a,c,d,e,f,g.
Let's say the maximum match of this graph is a,d,e.
Now you remove c from the input graph and get a,b,d,e,f,g.
Let's say the maximum match of this graph is a,b,g.
Now either c,d,e, a,d,e or a,b,g will be the second-most optimal (let's say it's a,b,g).
Now try to remove a, b, then g from a,b,d,e,f,g and get the maximum match of each of those 3 graph.
One of these 5 sets (the 6 generated sets excluding the second-most optimal one) should be the third optimal one.
And so on.
Proof:
I'll have to think about that a bit more...
Note:
For example, let's say we have edges a,b,c,d,e with a maximum match of a,b,c.
We remove a and get c,d,e as the maximum match.
We remove b and get c,d,e as the maximum match.
Note that these two are identical, so you shouldn't one as the second-most optimal and another as the third-most optimal.
Although you should keep both around - you need to check the graphs generated from removing c, d and e from both b,c,d,e and a,c,d,e.
Since you will need to check all the edges removed from both when c,d,e is the next-most optimal, this may negatively affect running time a bit.
I am aware that Dijkstra's algorithm can find the minimum distance between two nodes (or in case of a metro - stations). My question though concerns finding the minimum number of transfers between two stations. Moreover, out of all the minimum transfer paths I want the one with the shortest time.
Now in order to find a minimum-transfer path I utilize a specialized BFS applied to metro lines, but it does not guarantee that the path found is the shortest among all other minimum-transfer paths.
I was thinking that perhaps modifying Dijkstra's algorithm might help - by heuristically adding weight (time) for each transfer, such that it would deter the algorithm from making transfer to a different line. But in this case I would need to find the transfer weights empirically.
Addition to the question:
I have been recommended to add a "penalty" to each time the algorithm wants to transfer to a different subway line. Here I explain some of my concerns about that.
I have put off this problem for a few days and got back to it today. After looking at the problem again it looks like doing Dijkstra algorithm on stations and figuring out where the transfer occurs is hard, it's not as obvious as one might think.
Here's an example:
If here I have a partial graph (just 4 stations) and their metro lines: A (red), B (red, blue), C (red), D (blue). Let station A be the source.
And the connections are :
---- D(blue) - B (blue, red) - A (red) - C (red) -----
If I follow the Dijkstra algorithm: initially I place A into the queue, then dequeue A in the 1st iteration and look at its neighbors :
B and C, I update their distances according to the weights A-B and A-C. Now even though B connects two lines, at this point I don't know
if I need to make a transfer at B, so I do not add the "penalty" for a transfer.
Let's say that the distance between A-B < A-C, which causes on the next iteration for B to be dequeued. Its neighbor is D and only at this
point I see that the transfer had to be made at B. But B has already been processed (dequeued). S
So I am not sure how this "delay" in determining the need for transfer would affect the integrity of the algorithm.
Any thoughts?
You can make each of your weights a pair: (# of transfers, time). You can add these weights in the obvious way, and compare them in lexicographic order (compare # of transfers first, use time as the tiebreaker).
Of course, as others have mentioned, using K * (# of transfers) + time for some large enough K produces the same effect as long as you know the maximum time apriori and you don't run out of bits in your weight storage.
I'm going to be describing my solution using the A* Algorithm, which I consider to be an extension (and an improvement -- please don't shoot me) of Dijkstra's Algorithm that is easier to intuitively understand. The basics of it goes like this:
Add the starting path to the priority queue, weighted by distance-so-far + minimum distance to goal
Every iteration, take the lowest weighted path and explode it into every path that is one step from it (discarding paths that wrap around themselves) and put it back into the queue. Stop if you find a path that ends in the goal.
Instead of making your weight simply distance-so-far + minimum-distance-to-goal, you could use two weights: Stops and Distance/Time, compared this way:
Basically, to compare:
Compare stops first, and report this comparison if possible (i.e., if they aren't the same)
If stops are equal, compare distance traveled
And sort your queue this way.
If you've ever played Mario Party, think of stops as Stars and distance as Coins. In the middle of the game, a person with two stars and ten coins is going to be above someone with one star and fifty coins.
Doing this guarantees that the first node you take out of your priority queue will be the level that has the least amount of stops possible.
You have the right idea, but you don't really need to find the transfer weights empirically -- you just have to ensure that the weight for a single transfer is greater than the weight for the longest possible travel time. You should be pretty safe if you give a transfer a weight equivalent to, say, a year of travel time.
As Amadan noted in a comment, it's all about creating right graph. I'll just describe it in more details.
Consider two vertexes (stations) to have edge if they are on a single line. With this graph (and weights 1) you will find minimum number of transitions with Dijkstra.
Now, lets assume that maximum travel time is always less 10000 (use your constant). Then, weight of edge AB (A and B are on one line) is a time_to_travel_between(A, B) + 10000.
Running Dijkstra on such graph will guarantee that minimal number of transitions is used and minimum time is reached in the second place.
update on comment
Let's "prove" it. There're two solution: with 2 transfers and 40 minutes travel time and with 3 transfers and 25 minutes travel time. In first case you travel on 3 lines, so path weight will be 3*10000 + 40. In second: 4*10000 + 25. First solution will be chosen.
I had the same problem as you, until now. I was using Dijkstra. The penalties for transfers is a very good idea indeed and I've been using it for a while now. The main problem is that you cannot use it directly in the weight as you first you have to identify the transfer. And I didn't want to modify the algorithm.
So what I'be been doing, is that each time and you find a transfer, delete the node, add it with the penalty weight and rerun the graph.
But this way I found out that Dijkstra wont work. And this is where I tried Floyd-Warshall which au contraire to Dijkstra compares all possible paths through the graph between each pair of vertices.
It helped me with my problem switching to Floyd-Warshall. Hope it helps you as well.
Its easier to code and lot more easier to implement.