背景

该旅行商问题（TSP）要求在最短的电路访问城市的指定集合。出于这个问题的目的，城市将是平面中的点，城市之间的距离将是通常的欧几里得距离（四舍五入到最接近的整数）。赛道必须“往返”，这意味着它必须返回出发城市。

在协和TSP求解器可以解决旅行推销员问题的情况下，准确和速度远远超过人们所期望的。例如，协和飞机能够精确地求解85,900点实例，其中的一部分如下所示：

但是，即使对于协和飞机，某些TSP实例也会花费太长时间。例如，没有人能够解决基于Mona Lisa的100,000点实例。（如果您能解决的话，将提供1,000美元的奖金！）

Concorde 可作为源代码或可执行文件下载。默认情况下，它使用内置的线性程序（LP）求解器QSopt，但它也可以使用更好的LP求解器，例如CPLEX。

挑战

您可以生成花费最少五分钟的 Concorde的最小TSP实例是什么？

您可以编写一个程序来输出实例，或使用您想要的任何其他方法。

计分

实例中的点越少越好。关系将被实例的文件大小破坏（请参见下文）。

标准化

不同的计算机运行得更快或更慢，因此我们将Concorde的NEOS服务器用作运行时的衡量标准。您可以采用以下简单的2维坐标形式提交点列表：

#cities
x_0 y_0
x_1 y_1
.
.
.
x_n-1 y_n-1

NEOS上应使用的设置为“协和数据（xy-list文件，L2规范）”，“算法：协和（QSopt）”和“随机种子：固定”。

基准线

在1889点的情况下rl1889.tsp，从TSPLIB以“总的运行时间：871.18（秒）”，这是超过五分钟。看起来像这样：

NEOS上88个城市的运行时间为341秒

在最近的一篇论文中，我们构建了一个难以解决的欧几里得TSP实例族。您可以从该系列下载实例，并在此处下载生成它们的代码：

http://www.or.uni-bonn.de/%7Ehougardy/HardTSPInstances.html

这个家庭的88个城市实例在NEOS服务器上花费了5分钟以上的时间。来自这个家庭的178个城市实例需要一天多的时间才能解决。

NEOS上77个城市的平均运行时间为7.24分钟（434.4秒）

我参加聚会有点晚了，但是我想贡献一个77节点的实例weruSnowflake77。

在创建实例时，我试图了解哪种局部和全局特征会对协和曲调以使其最佳下限与其最短发现行程的长度相匹配所花费的时间增加压力。

为了构造该实例，我从一个基础图（13 x 13正方形）开始，然后系统地引入新点或翻译的旧点，保留似乎使协和点平均切入分支之前的调整。

该技术类似于遗传算法变异现有巡回路线并为下一代突变保留较短巡回路线的方式，除了图形本身正在变异且难以解决的图形得以保留。这也类似于我们使用松弛对图进行变异以帮助构建良好的下界的方式，除了我正相反，对现有图进行变异以构建难以找到下界的图。

在此过程中，我发现了一些较小的图表，需要花费几分钟的时间才能解决，但这是我发现的第一个较小的图表，需要花费最少5分钟的时间。

使用固定种子和QSopt在NEOS上进行了10次试运行，平均运行时间为7.24分钟（434.531秒）。最小运行时间为5.6分钟（336.64秒）。最大运行时间为8.6分钟（515.80秒）。没有试验被丢弃。完整的基准测试表如下：

基准测试结果超过10次：

----------------------------------
| Run | Job ID# | Total running  |
|     |         | time (seconds) |
|-----|---------|----------------|
| 1   | 7739963 | 513.44         |
| 2   | 7740009 | 336.64         |
| 3   | 7740023 | 514.25         |
| 4   | 7740029 | 447.97         |
| 5   | 7740038 | 357.10         |
| 6   | 7740072 | 447.47         |
| 7   | 7740073 | 336.19         |
| 8   | 7740075 | 515.80         |
| 9   | 7740088 | 361.26         |
| 10  | 7740091 | 515.19         |
----------------------------------

weruSnowflake77（xy列表，L2规范）：

77
-700 -700
700 -700
200 0
0 200
-200 0
0 -200
0 0
-600 600
-500 600
-400 600
-300 600
-200 600
-100 600
0 600
100 600
200 600
300 600
400 600
500 600
600 600
-600 -600
-500 -600
-400 -600
-300 -600
-200 -600
-100 -600
0 -600
100 -600
200 -600
300 -600
400 -600
500 -600
600 -600
600 -500
600 -400
600 -300
600 -200
600 -100
600 0
600 100
600 200
600 300
600 400
600 500
-600 -500
-600 -400
-600 -300
-600 -200
-600 -100
-600 0
-600 100
-600 200
-600 300
-600 400
-600 500
-500 -500
-400 -400
-300 -300
-200 -200
-100 -100
100 100
200 200
300 300
400 400
500 500
100 -100
200 -200
300 -300
400 -400
500 -500
-100 100
-200 200
-300 300
-400 400
-500 500
700 700
-700 700

资料库

• GitHub网址：https : //github.com/LDubya/weruSnowflake77

回购中的问题集文件：

• weruSnowflake77.txt（xy列表文件，L2规范）
• weruSnowflake77.tsp（TSPLIB格式，EUC_2D）

Python 3，911个城市，NEOS上的运行时间为1418秒

以下Python 3.x脚本生成911个城市的坐标。NEOS花了1418秒来计算最短路径47739。

这是最短路径的图片（感谢A. Rex）：

代码/算法基于Feigenbaum分叉，我用来生成一系列值，这些值用作生成城市坐标的基础。我对参数进行了实验，直到发现1000个以下的城市花了NEOS惊人的时间（远远超过了所需的5分钟）。

x = 0.579
coords = []
for _ in range(1301):
    if int(3001*x) not in coords:
        coords.append(int(3001*x))
    x = 3.8*x*(1-x)
coords = list(zip(coords, coords[::-1]))
print(len(coords))
for coord in coords:
    print(f"{coord[0]} {coord[1]}")

PS：我正在运行一个脚本来搜索数量较少的城市，这些城市在NEOS上也要花费5分钟以上。如果发现任何问题，我会在此答案中发布它们。

PS：该死！使用l参数1811而不是1301 运行此脚本会导致1156个城市在NEOS上的运行时间刚刚超过4小时，这比其他具有类似参数的情况要多得多。