Travelling Salesman Problem看法和我感觉不错的解决思路

最近看数据结构，看到了tsp问题，觉得很有趣，就去搜索了相关算法，但是大多都是运行时间很久（我看几个算法演示结果的图片，其实效果也不好，实际就不懂了），贪心算法快但是效果最差。

我看过研究说蜜蜂能很好解决tsp问题，我们人也能在节点比较少的时候，很快找到一条不错 的路径，我觉得这是因为知道节点的前后位置，节点与节点的距离有很大关系，我看过几个算法都没有用节点的位置这个条件（也就是坐标这个条件，其实那些算法我没看过，只是看过原理，代码用c++写的我根本看不下去 ），但是其实很多现实的tsp问题都有位置这个条件的，当年提出这个问题：有n个城市，一个推销员要从其中某一个城市出发，唯一走遍所有的城市，再回到他出发的城市，求最短的路线。在解决这个问题的时候只关注每个点与另外点的距离，从来不关注位置。在我看来，如果把tsp看做对象，那么加入位置这个条件那么就变成一个实例，加入位置这个条件可以迅速找到一条比较好的路径。

   按照上面的想法，我在自己电脑用c#编写小程序测试2000个节点，没有多线程，时间只花了三四秒，其中大部分是在生成坐标，和各个节点的距离排序，到真正找路径实际应该不到一秒，但是因为我编程基础差，效果也达不到我的预期

 我的程序思路是这样的

1.随机生成n个坐标；

2.计算每个点到其他点的距离，并从小到大排序，（程序时间基本都是耗在这里，程序也基本很多时候要靠距离和位置来做出选择）

3.随机选一个起点作为起始点，并加入链表；

4.从链表获取到最后一节点，根据这个节点（记做p），找到离这个节点最近的节点，记做closeP（有点类似贪心算法，只不过多加几个逻辑，这也是上面排序的原因），我们可以几个逻辑判断是否要连上closeP

1）如果closeP的最近两个节点都是已经被连接的，那就判断把closeP加入里它最近的两个节点合算还是直接和p连接合算

2）如果最近的一个节点已经连接

        3）如果最近的两个节点都没有连接，那么就连上closeP，

4）等等其他。。。。

上面几个逻辑还可以做细节优化

5.连上下个节点之前，要判断有没有这样连接会不会穿越之前路线，如果穿越了（这就要坐标计算了，那p节点半径内的节点都拿来计算有没有穿越，还没加入链表的不算，，半径可以通过节点的密度计算），那么就把链表改下，比如穿越了a,b （a->b）两个节点，那么就把a之后的节点都反序，比如本来是，abcdef 就变成afedcb ,然后再通过b去连那个closeP，直到连上

循环 4~5 这样所以节点都连上了，这样一条路径就找到了，然后再优化这条路径，比如链表某个节点的离下一个节点距离大于坐标密度，就根据一些逻辑优化，还有进行局部最优化处理

这样完之后基本一条比较好的路径就出来了

我觉得如果实际问题不要求最优解又要时间快，我觉得这方法不错，有一定概率碰到最优解最后我想说，这些都是我自己想象的结果，如果已经有出现这样想法，或者我这个想法实际结果差强人意，那么赶紧把这篇文章删了，我写的这边文章的目的是我不想花时间去想这个问题了，因为结果可能不错（可以几秒内对上万个节点查找，路径也满足需求），也可能很差（很垃圾，找到的路径和可接受的路径差太多），但我根本无力验证，不想浪费时间了，也希望如果有对算法或者tsp问题有研究 的大神给我些建议