Suppose there is a median scale which takes an input of three coins and returns the median among three coins, it won't tell anything about the rest of two coins. How can we find the lightest and heaviest among the coins using O(nlgn).Provided there are n distinct coins.
The lightest and heaviest coins are the only ones that aren't the median of any group.
Pick any 3 coins and discard the median. Repeat until there are only 2 left.
Since each operation discards a coin, this takes O(n) time.
Related
If the distance between two points drops at n iteration,we know there must be a negative cycle.
My question is that if there is a negative cycle, will the distance between two points 100% drop at n iteration?
Not two arbitrary points, but yes, if the graph has a negative cycle, then Bellman-Ford will update at least one distance in every iteration, no matter how many iterations you do.
The distances on the negative cycle get smaller and smaller, approaching -infinity.
Question
How would one going about finding a least cost path when the destination is unknown, but the number of edges traversed is a fixed value? Is there a specific name for this problem, or for an algorithm to solve it?
Note that maybe the term "walk" is more appropriate than "path", I'm not sure.
Explanation
Say you have a weighted graph, and you start at vertex V1. The goal is to find a path of length N (where N is the number of edges traversed, can cross the same edge multiple times, can revisit vertices) that has the smallest cost. This process would need to be repeated for all possible starting vertices.
As an additional heuristic, consider a turn-based game where there are rooms connected by corridors. Each corridor has a cost associated with it, and your final score is lowered by an amount equal to each cost 'paid'. It takes 1 turn to traverse a corridor, and the game lasts 10 turns. You can stay in a room (self-loop), but staying put has a cost associated with it too. If you know the cost of all corridors (and for staying put in each room; i.e., you know the weighted graph), what is the optimal (highest-scoring) path to take for a 10-turn (or N-turn) game? You can revisit rooms and corridors.
Possible Approach (likely to fail)
I was originally thinking of using Dijkstra's algorithm to find least cost path between all pairs of vertices, and then for each starting vertex subset the LCP's of length N. However, I realized that this might not give the LCP of length N for a given starting vertex. For example, Dijkstra's LCP between V1 and V2 might have length < N, and Dijkstra's might have excluded an unnecessary but low-cost edge, which, if included, would have made the path length equal N.
It's an interesting fact that if A is the adjacency matrix and you compute Ak using addition and min in place of the usual multiply and sum used in normal matrix multiplication, then Ak[i,j] is the length of the shortest path from node i to node j with exactly k edges. Now the trick is to use repeated squaring so that Ak needs only log k matrix multiply ops.
If you need the path in addition to the minimum length, you must track where the result of each min operation came from.
For your purposes, you want the location of the min of each row of the result matrix and corresponding path.
This is a good algorithm if the graph is dense. If it's sparse, then doing one bread-first search per node to depth k will be faster.
Here is the problem:
Given an array represents the lengths of rods on the table. Every time pick two rods and connect them and get a new rod. Do this until there is only one rod on the table.
The cost of a connection is the sum of two rods' lengths, for example, connect 2 with 3 will get a 5 rod and cost 5.
What is the minimum cost connection strategy?
Greedy: every time pick the shortest two and put the connected new rod back to the table.
Example:
[1,2,3,4,5] , pick 1 and 2 cost 3 [3,3,4,5], pick 3 and 3 cost 6 [4,5,6], pick 4 and 5 cost 9 [6,9], pick 6 and 9 cost 15. So that the total cost is 33.
We can't simply say that, total times of connection is the same n-1 so that every time picking smallest two will give a final minimum cost. Because every picking will change the future, like picking 1+2 and picking 2+4 will result in two different sets of rods for the next step.
How can I prove this greedy will get minimum cost?
The proof is similar to a proof that Huffman'c code is optimal.
There's a binary tree corresponding to each strategy. It contains all initial rods in its leaves and inner vertices correspond to connection operations.
One can see that the cost of connecting the rods for a fixed tree is the sum of a[v] * depth[v] over all leaves v, where a[v] is the length of the initial rod and depth[v] is the depth of the leave. It's the case because each rod takes part in a connection exactly depth[v] times.
We need to show that there exists an optimal strategy such that its tree has two shortest rods as siblings.
Let assume that T is an optimal tree. Let's sort it's leaves by their depths (in non-strictly decreasing order). If the two shortest rods are the first two leaves, we're done. Otherwise, let's keep swapping them with their left sibling (which is at least as long as them) until they get into the first two positions. When we swap 2 leaves u and v, the cost change is -depth[u] * a[u] - depth[v] * a[v] + depth[u] * a[v] + depth[v] * a[u] = (depth[v] - depth[u]) * (a[u] - a[v]). The first term is non-positive (as the leaves were sorted by their height) and the second term is non-negative (as a[u] >= a[v]). Thus, the cost change is negative or zero.
Hence, there exists an optimal tree where two shortest rods are siblings. It means that there's an optimal strategy where we connect these two rods before we do anything else.
We are given N pairs. Each pair contains two numbers. We have to find maximum number K such that if we take any combination of J (1<=J<=K) pairs from the given N pairs, we have at least J different numbers in all those selected J pairs. We can have more than one pair same.
For example, consider the pairs
(1,2)
(1,2)
(1,2)
(7,8)
(9,10)
For this case K = 2, because for K > 2, if we select three pairs of (1,2), we have only two different numbers i.e 1 and 2.
Checking for each possible combination starting from one will take a very large amount of time. What would be an efficient algorithm for solving the problem?
Create a graph with one vertex for each number and one edge for each pair.
If this graph is a chain or a tree, we have the number of "numbers", equal to number of "pairs" plus one, After removing any number of edges from this graph, we never get less vertexes than edges.
Now add a single cycle to this chain/tree. There is equal number of vertexes and edges. After removing any number of edges from this graph, again we never get less vertexes than edges.
Now add any number of disconnected components, each should not contain more than one cycle. Once again, we never get less vertexes than edges after removing any number of edges.
Now add a second cycle to any of disconnected components. After removing all other components. at last we have more edges than vertexes (more pairs than numbers).
All this leads to the conclusion that K+1 is exactly the number of edges in the smallest possible subgraph, consisting of two cycles and, possibly, a chain, connecting these cycles.
Algorithm:
For each connected component, find the shortest cycle going through every node with Floyd-Warshall algorithm.
Then for each non-overlapping pair of cycles (in single component), use Dijkstra’s algorithm, starting from any node with at least 3 edges in one cycle, to find shortest path to other cycle; and compute a sum of lengths of both cycles and a shortest path, connecting them. For each overlapping pair of cycles, just compute the number of their edges.
Now find the minimum length of all these subgraphs. And subtract 1.
The above algorithm computes K if there is at least one double-cycle component in the graph. If there are no such components, K = N.
Seems related to MinCut/MaxFlow. Here is a try to reduce it to MinCut/MaxFlow:
- Produce one vertex for each number
- Produce one vertex for each pair
- Produce an edge from number i to a pair if the number is present in the pair, weight 1
- Produce a source node and connect it to all numbers, weight 1 for each connection
- Produce a sink node and connect it to all numbers, weight 1 for each connection
Running MaxFlow on this should give you the number K, since any set of three pairs which only contains two numbers in total, will be "blocked" by the constrains on the outgoing edges from the number.
I am not sure whether this is the fastest solution. There might also be a matroid hidden in there somewhere, I think. In that case there is a greedy approach. But I cannot find a proof for the matroid properties of the sets you are constructing.
I made some progress on it, but not yet an efficient solution. However it may point the way.
Make a graph whose points are pairs, and connect any pair of points if they share a number. Then for any subgraph, the number of numbers in it is the number of vertices minus the number of edges. Therefore your problem is the same as locating the smallest subgraph (if any) that has more edges than vertices.
A minimal subgraph that has the same number of edges and vertices is a cycle. Therefore the graphs we're looking for are either 2 cycles that share one or more vertices, or else 2 cycles which are connected by a path. There are no other minimal types possible.
You can locate and enumerate cycles fairly easily with a breadth-first search. There may be a lot of them, but this is doable. Armed with that you can look for subgraphs of these subtypes. (Enumerate minimal cycles, look for either pairs that share points, or which are connected.) But that isn't guaranteed to be polynomial. I suspect it will be something where on average it is pretty good, but the worst case is very bad. However that may be more efficient than what you're doing now.
I keep on thinking that some kind of breadth-first search can find these in polynomial time, but I keep failing to see exactly how to do it.
This is equivalent to finding the chord that chords the smallest cycle in the graph. A very naive algorithm would be:
Check if removal of an edge results in a cycle containing the vertices corresponding to the edge. If yes, then note down the length of the smallest cycle.
There's an undirected graph with weights on edges (weights are non-negative integers and their sum isn't big, most are 0). I need to divide it into some number of subgraphs (let's say graph of 20 nodes to 4 subgraphs of 5 nodes each) in a way that minimizes sum of weights of edges between different subgraphs.
This sounds vaguely like the minimum cut problem, but not quite close enough.
In alternative formulation - there's a bunch of buckets, all items belong to exactly two buckets, and I need to partition buckets into bucket groups in a way that minimizes number of items in more than one bucket group. (nodes map to buckets, edge weights map to duplicate item counts)
This is the minimum k-cut problem, and is NP hard. Here's a greedy heuristic that will guarantee you a 2-1/k approximation:
While the graph has fewer than k components:
1) Find a min-cut in each component
2) Split the component with the smallest weight min-cut.
The problem is studied in this paper: http://www.cc.gatech.edu/~vazirani/k-cut.ps