<p>&quot;If one takes the 2 nearest neighbors of every node and adds them all up, that is a theoretical minimum.&quot;
This isn't true. You are adding up 2 edges per vertex, where a TSP solution has one edge per vertex. Unless I am misunderstanding what you mean.</p>
<p>However, nearest-neighbor is a classic  heuristic for TSP. Arbitrarily pick a vertex to start, connect it to its nearest neighbor. Connect that vertex to its nearest neighbor that hasn't yet been connected. However, the length of a tour returned by this heuristic can be arbitrarily bigger than the optimal length.</p>
<p>You could modify this heuristic so it connects a vertex to its nearest neighbor, even if it has already been found, and that could be the starting point of your &quot;bottom up solution&quot;. However, I still don't think this will necessarily be a lower bound of the optimal solution (or at least it isn't obvious to me that it would be).</p>
<p>Finally, you say, &quot;it might be better than NN.&quot; What is &quot;NN&quot;? Also are you interested in solving the problem in theory or practice? Because in practice TSP can be solved to optimality relative quickly using integer programming techniques.</p>

CC BY-SA 4.0
2023-10-02T22:44:31.600Z
2023-10-02T22:44:31.600Z
NaturalLogZ
<p>I noticed you made an edit to your question so I now better understand your proposed algorithm. My misunderstanding was large enough that I think it makes more sense to post a new answer.</p>
<p>First, I have a question. What do you mean by &quot;n/2 pairs of unconnected cycles&quot;? My interpretation was &quot;n/2 disconnected cycles of length 2&quot;. If my interpretation is correct, I think you've made a small mistake in reasoning though. One vertex could be the nearest neighbour for several vertices. For example if you have 6 vertices, one at the origin and the other 5 evenly spaced on the unit disk, then the vertex at the origin is the nearest neighbour for each of the other 5.</p>
<p>Also, when connecting cycles to their nearest neighbour cycles, you need to describe what procedure you would be using to do that. I assume you are measuring the distance between two cycles <span class="math-container">$C_1$</span> and <span class="math-container">$C_2$</span> as the minimum distance between a vertex <span class="math-container">$v_1 \in C_1$</span> and a vertex <span class="math-container">$v_2 \in C_2$</span>. Let us say that <span class="math-container">$C_1$</span>'s nearest neighbour is <span class="math-container">$C_2$</span> and the vertices <span class="math-container">$v_1 \in C_1$</span> and <span class="math-container">$v_2 \in C_2$</span> are the closest vertices. Given this info, how do you connect <span class="math-container">$C_1$</span> and <span class="math-container">$C_2$</span> to get a new cycle?</p>
<p>To answer the high-level question of why no one has studied a &quot;bottom up&quot; approach to TSP we should first make sure we mean the same thing by &quot;bottom up&quot;. I thought you meant a method where we make locally optimal decisions for each vertex, and mentioned that such methods have been studied. I specifically mentioned the Nearest-Neighbour Heuristic, which has been very extensively studied, but there are others as well. If that isn't what you mean, could you please clarify?</p>

CC BY-SA 4.0
2023-10-12T22:30:58.600Z
2023-10-12T22:30:58.600Z
NaturalLogZ
<p>I'm not sure if this is something new or if I'm just not getting previous efforts. TSP can be thought of as a list of weighted links and nodes. If one takes the Nearest Neighbor (NN) of every node and adds them all up, that is a theoretical minimum. It's not a solution, but any solution can't be less than that. It will produce n/2 pairs of unconnected cycles. Label all of the nodes in the cycle with the cycle's label. Next, connect the nearest adjacent cycle. Relabel the cycles. When the cycle count reaches 1, you have a solution. It's probably not optimal, but it might be better than NN. Just thought I'd ask. Any help is appreciated. I did try to look it up, but all the solutions looked top down to me, so hopefully, I haven't wasted everyone's time.</p>
<p>Response,</p>
<p>Thanks for the responses, they've been very helpful. This truly is a question and not a proposal masquerading as one, so the answer to many of your questions is, I don't know.</p>
<p>Your example struck me as odd for something on a plane, but a simple circle with r=1 radian demonstrates it. It comes down to 1r vs 1.23 approx.</p>
<p>My thinking was using something like a parallel merge sort.  I think of NN more like a sequential bubble sort. So the goal is to create small cycles and then merge them into larger ones. In cases of ties, instead of going to the runner, they go to the node with the fewest good options. Each node could be represented as a table with all it's links sorted by weight. Each link would also have a cycle ID associated with it. This was more like a component labeling problem from imagine processing. Once a link is in the same cycle, they would be deactivated. The goal here is to try to decrease the run time to log2(n) but more likely log2(n)*log2(n). It's the type of problem that should, in theory, run well on SIMD grid of processors, although I suspect they will need local memory decode. It would also require some sort of higher level routing, in days gone by a hypercube or butterfly switch was used. Decades ago I did some research on a pyramid topology system for component labeling and saw some improvement. A single spiral was the worse case, which was &lt; log2(n)*log2(n) if memory serves.</p>

CC BY-SA 4.0
2023-10-11T16:47:56.073Z
Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking.
Community
CC BY-SA 4.0
2023-10-15T16:43:48.033Z
A similar way is to find a min-weight disjoint (vertex) cycle cover (https://en.wikipedia.org/wiki/Vertex_cycle_cover), contract each cycle in it, and recurse on the contracted graph.  (Finding the min-wt cover is poly-time by reduction to min-weight bipartite matching.)  Each step at least halves the number of vertices, so there are at most $\log n$ steps.  The cost of the cover at each step is a lower-bound on OPT, so the total cost of the resulting edges (which connect the graph) is at most $\log(n)\times$ OPT.   In a metric graph shortcutting the edges gives a tour.  There are better algs.
Neal Young
CC BY-SA 4.0
2023-10-15T22:15:58.750Z
Ah if your goal is to devise a heuristic that will run well on SIMD processors, then your ideas very well might lead to such an algorithm. I think it could be interesting to implement such an algorithm, run it on a database of standardized tsp instances, and see how it stacks up to other methods. However, as @NealYoung mentioned your algorithm is likely to not be as good as existing algorithms in the ways that theoretical computer scientists care about. The simple 2-approximation based on the minimum spanning tree already has a run time of $O(n\log n)$.
NaturalLogZ
<graph-theory><p-vs-np><tsp>
Bottom up TSP solution?
Maub Nesor
# Bottom up TSP solution?

(Asked by: username_0 on 2023-10-02)

I'm not sure if this is something new or if I'm just not getting previous efforts. TSP can be thought of as a list of weighted links and nodes. If one takes the Nearest Neighbor (NN) of every node and adds them all up, that is a theoretical minimum. It's not a solution, but any solution can't be less than that. It will produce n/2 pairs of unconnected cycles. Label all of the nodes in the cycle with the cycle's label. Next, connect the nearest adjacent cycle. Relabel the cycles. When the cycle count reaches 1, you have a solution. It's probably not optimal, but it might be better than NN. Just thought I'd ask. Any help is appreciated. I did try to look it up, but all the solutions looked top down to me, so hopefully, I haven't wasted everyone's time.

Response,

Thanks for the responses, they've been very helpful. This truly is a question and not a proposal masquerading as one, so the answer to many of your questions is, I don't know.

Your example struck me as odd for something on a plane, but a simple circle with r=1 radian demonstrates it. It comes down to 1r vs 1.23 approx.

My thinking was using something like a parallel merge sort. I think of NN more like a sequential bubble sort. So the goal is to create small cycles and then merge them into larger ones. In cases of ties, instead of going to the runner, they go to the node with the fewest good options. Each node could be represented as a table with all it's links sorted by weight. Each link would also have a cycle ID associated with it. This was more like a component labeling problem from imagine processing. Once a link is in the same cycle, they would be deactivated. The goal here is to try to decrease the run time to log2(n) but more likely log2(n)\*log2(n). It's the type of problem that should, in theory, run well on SIMD grid of processors, although I suspect they will need local memory decode. It would also require some sort of higher level routing, in days gone by a hypercube or butterfly switch was used. Decades ago I did some research on a pyramid topology system for component labeling and saw some improvement. A single spiral was the worse case, which was < log2(n)\*log2(n) if memory serves.

**Tags:** graph-theory, p-vs-np, tsp

> **Comments:**
> **username_1**: Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking.  
> **username_2**: A similar way is to find a min-weight disjoint (vertex) cycle cover (https://en.wikipedia.org/wiki/Vertex_cycle_cover), contract each cycle in it, and recurse on the contracted graph.  (Finding the min-wt cover is poly-time by reduction to min-weight bipartite matching.)  Each step at least halves the number of vertices, so there are at most $\log n$ steps.  The cost of the cover at each step is a lower-bound on OPT, so the total cost of the resulting edges (which connect the graph) is at most $\log(n)\times$ OPT.   In a metric graph shortcutting the edges gives a tour.  There are better algs.  
> **username_3**: Ah if your goal is to devise a heuristic that will run well on SIMD processors, then your ideas very well might lead to such an algorithm. I think it could be interesting to implement such an algorithm, run it on a database of standardized tsp instances, and see how it stacks up to other methods. However, as @NealYoung mentioned your algorithm is likely to not be as good as existing algorithms in the ways that theoretical computer scientists care about. The simple 2-approximation based on the minimum spanning tree already has a run time of $O(n\log n)$.  

---

## 2 answers

### Answer by username_3 on 2023-10-02. Score: 1

"If one takes the 2 nearest neighbors of every node and adds them all up, that is a theoretical minimum."
This isn't true. You are adding up 2 edges per vertex, where a TSP solution has one edge per vertex. Unless I am misunderstanding what you mean.

However, nearest-neighbor is a classic heuristic for TSP. Arbitrarily pick a vertex to start, connect it to its nearest neighbor. Connect that vertex to its nearest neighbor that hasn't yet been connected. However, the length of a tour returned by this heuristic can be arbitrarily bigger than the optimal length.

You could modify this heuristic so it connects a vertex to its nearest neighbor, even if it has already been found, and that could be the starting point of your "bottom up solution". However, I still don't think this will necessarily be a lower bound of the optimal solution (or at least it isn't obvious to me that it would be).

Finally, you say, "it might be better than NN." What is "NN"? Also are you interested in solving the problem in theory or practice? Because in practice TSP can be solved to optimality relative quickly using integer programming techniques.


---

### Answer by username_3 on 2023-10-12. Score: 0

I noticed you made an edit to your question so I now better understand your proposed algorithm. My misunderstanding was large enough that I think it makes more sense to post a new answer.

First, I have a question. What do you mean by "n/2 pairs of unconnected cycles"? My interpretation was "n/2 disconnected cycles of length 2". If my interpretation is correct, I think you've made a small mistake in reasoning though. One vertex could be the nearest neighbour for several vertices. For example if you have 6 vertices, one at the origin and the other 5 evenly spaced on the unit disk, then the vertex at the origin is the nearest neighbour for each of the other 5.

Also, when connecting cycles to their nearest neighbour cycles, you need to describe what procedure you would be using to do that. I assume you are measuring the distance between two cycles $C\_1$ and $C\_2$ as the minimum distance between a vertex $v\_1 \in C\_1$ and a vertex $v\_2 \in C\_2$. Let us say that $C\_1$'s nearest neighbour is $C\_2$ and the vertices $v\_1 \in C\_1$ and $v\_2 \in C\_2$ are the closest vertices. Given this info, how do you connect $C\_1$ and $C\_2$ to get a new cycle?

To answer the high-level question of why no one has studied a "bottom up" approach to TSP we should first make sure we mean the same thing by "bottom up". I thought you meant a method where we make locally optimal decisions for each vertex, and mentioned that such methods have been studied. I specifically mentioned the Nearest-Neighbour Heuristic, which has been very extensively studied, but there are others as well. If that isn't what you mean, could you please clarify?


---

