I have some trouble trying to summarize the worst-case ratio of these heuristics for the metric (this means that it satisfies the triangle inequality) traveling salesman problem:
Nearest neighbor
Nearest insertion
Cheapest insertion
Farthest insertion
Nearest neighbor:
Here it says that the NN has a w-C ratio of
This one, page 8, same as this one says that it is
Which changes a lot.
Insertion algorithms:
Pretty match everyone agrees that the w-c ratio for cheapest and nearest insertion is <= 2 (always just for instances satisfying the triangle inequality) but coming to the farthest insertion every source is different:
here:
(forgot to change NN to FI)
While here
It is
And here there is also a different one:
Regarding the FI, I think that it depends on the starting sub-tour.
But in the NN, that ceil or floor bracket changes a lot the results, and since they all come from good sources, I can't figure out the right one.
Can someone summerize the actual known worst-case ratio for these algorithms?
NN: The correct bound uses ceiling, not floor (at least as proved in the original paper by Rosenkrantz et al. -- here, if you have access). I don't think there's a more recent bound that uses floor.
FI: Rosenkrantz et al. prove that the first bound applies to any insertion heuristic, including NN. Moreover, that bound is better than the other two (except for very small n). So I would use that bound. Note, however, that log really means log_2 in that formula. (I'm not sure where the other two bounds came from.)
One other note: It is known that there is no fixed worst-case bound for NN. It is not known whether there is a fixed worst-case bound for FI.
Related
I'm reading CLRS Algorithms Edition 3 and I have two problems for my homework (I'm not asking for answers, I promise!). They are essentially the same question, just applied to Kruskal or to Prim. They are as follows:
Suppose that all edge weights in a graph are integers in the range from 1 to |V|. How fast can you make [Prim/Kruskal]'s algorithm run? What if the edge weights are integers in the range from 1 to W for some constant W?
I can see the logic behind the answers I'm thinking of and what I'm finding online (ie sort the edge weights using a linear sort, change the data structure being used, etc), so I don't need help answering it. But I'm wondering why there is a difference between the answer if the range is 1 to |V| and 1 to W. Why ask the same question twice? If it's some constant W, it could literally be anything. But honestly, so could |V| - we could have a crazy large graph, or a very small one. I'm not sure how the two questions posed in this problem are different, and why I need two separate approaches for both of them.
There's a difference in complexity between an algorithm that runs in O(V) time and O(W) time for constant W. Sure, V could be anything, as could W, but that's not really the point: one is linear, one, is O(1). The question is then for which algorithms could having a restricted range of edge-weights impact complexity (based, as you suggest on edge-weight sort time and choice in data-structure), and what would the actual new optimal complexity be for linearly bounded edge-weights vs. for edge-weights bounded by a constant, W.
Having bounded edge-weights could open up new possibilities for sorting algorithms for Kruskal's, and might change the data structure you'd want to use to implement the queue for Prim's along with the most optimal way you could implement extract-min and update-key operations for that queue. The extent to which edge-weights are bounded can impact whether a particular change in data structure or implementation is even beneficial to make in terms of final complexity.
For example, knowing that the n elements of a list are bounded in value by a constant W makes it so that a switch to radix sort would improve the asymptotic complexity of sorting them, but if I instead only knew that they were bounded in value by 2^n there would be no advantage in changing to radix sort over the traditional methods and their O(n*logn) sorting complexity.
I'm tutoring a student and one of her assignments is to describe an O(nlogn) algorithm for the closest pair of points in the one-dimensional case. But the restriction is she's not allowed to use a divide-and-conquer approach. I understand the two-dimensional case from a question a user posted some years ago. I'll link it in case someone wants to look at it: For 2-D case (plane) - "Closest pair of points" algorithm.
However, for the 1-D case, I can only think of a solution which involves checking each and every point on the line and comparing it to the closest point to the left and right of it. But this solution isn't O(nlogn) since checking each point will take time proportional to n and the comparisons for each point would take time proportional to 2n. I'm not sure where log(n) would come from without using a divide-and-conquer approach.
For some reason, I can't come up with a solution. Any help would be appreciated.
Hint: If the points were ordered from left to right, what would you do, and what would the complexity be? What is the complexity of ordering the points first?
It seems to me that one could:
Sort the locations into order - O(n log n)
Find the differences between the ordered locations - O(n)
Find the smallest difference - O(n)
The smallest difference defines the two closest points.
The overall result would be O(n log n).
We know the complexity of the nearest neighbor search of kd-tree is O(logn). But how to calculate it? The main problem is the average time complexity of the back tracing. I have tried to read the paper "An Algorithm for Finding Best Matches in Logarithmic Expected Time", but it is too complicate for me. Does anyone know a simple way to calculate that?
The calculation in the paper is about as simple as possible for a rigorous analysis.
(NB This is the price of being a true computer scientist and software engineer. You must put the effort into learning the math. Knowing the math is what separates people who think they can write solid programs from those who actually can. Jon Bentley, the guy who invented kd-trees, did so when he was in high school. Take this as inspiration.)
If you want a rough intuitive idea that is not rigorous, here is one.
Assume we are working in 2d. The sizes of the geometric areas represented by the 2d-tree are the key.
In the average case, one point partitions the domain into 2 roughly equal-sized rectangles. 3 points into 4. 7 points into 8 parts. Etc. In general N points lead to N-1 roughly equal-sized rectangles.
It not hard to see that if the domain is 1x1, the length of a side of these parts is on average O(sqrt(1/N)).
When you search for a nearest neighbor, you descend the tree to the rectangle containing the search point. After doing this, you have used O(log N) effort to find a point within R = O(sqrt(1/N)) of the correct one. This is just a point contained in the leaf that you discovered.
But this rectangle is not the only one that must be searched. You must still look at all others containing a point no more than distance R away from the search point, refining R each time you find a closer point.
Fortunately, the O(sqrt(1/N)) limit on R provides a tight bound on the average number of other rectangles this can be. In the average case, it's about 8 because each equal-sized rectangle has no more than 8 neighbors.
So the total effort to search is O(8 log n) = O(log n).
Again, I repeat this is not a rigorous analysis, but it ought to give you a feel for why the algorithm is O(log N) in the average case.
Is there a practical algorithm (not NP-hard) that can cut a graph into two approximately equal sub-graphs (e.g., One sub-graph has 40%-50% vertices), in the meantime, prove that the cut is the minimal possible cut given the condition that two sub-graphs have approximately equal number of vertices?
This is not exactly sparsest cut; it's balanced cut, also NP-hard, as described in Chapter 8 of Dasgupta, Papadimitriou, and Vazirani. The canonical version of the sparsest cut problem does not allow specification of the partition size.
There are two streams of research on graph partitioning problems: algorithms with worst-case approximation guarantees, of which Arora–Rao–Vazirani is the main result of interest to you, and algorithms without worst-case guarantees, which are evaluated by their practical performance (random example I have no experience with: METIS). Even though I don't know it very well, I'd be inclined to steer you toward the latter line of work; a priori, O(√log n) bicriteria approximation is just not a very useful guarantee, and there's likely to be some nontrivial algorithms engineering to get ARV working well at scale in the first place.
Say I am finding a path in a house using A* algorithm. Now the running time could be O(n^2).
I was thinking will it improve the performance if I knew which doors to follow and according I shall apply A* on it i.e. if I have the starting position S and final position as F, and instead of applying the A* on these two end points, will be be better if I applied the A* on
`S` and `A1`
`A1` and `A2`
`A2` and F.
Where A1 and A2 are my intermediates(doors) that shall be followed for the shortest path? Will it be worth the improvement to find the intermediates and then follow the path and not just apply A* directly on starting and ending.
Considering it takes linear time to find the intermediates.
Yes, that will help a lot in case the algorithm takes O(n^2) behavior at runtime. Instead of one big problem you get two smaller problems with each being 1/4 as expensive to compute.
I'm sure there are pathological cases where it doesn't help or even hurt but in your scenario (house) it would probably help a lot.
I imagine that you are using the fact that one has to go up an elevator or stairs to change floors. That would help A* a lot because the cost function now has to work only within a single floor. It will be very representative of the real cost. In contrast to that the cost function would be greatly underestimating the distance if you wanted to move into the same room but one floor higher. Euclidean distance would fail totally in that case (and the algorithm would degrade into an exhaustive search). First moving to the stairs and then moving from the stairs to the desired room would work much better.