fundo

O problema do vendedor ambulante (TSP) solicita o menor circuito que visita uma determinada coleção de cidades. Para os fins desta pergunta, as cidades serão pontos no plano e as distâncias entre elas serão as distâncias euclidianas usuais (arredondadas para o número inteiro mais próximo). O circuito deve ser "ida e volta", o que significa que deve retornar à cidade inicial.

O solucionador Concorde TSP pode resolver instâncias do problema do vendedor ambulante euclidiano, exatamente e muito mais rapidamente do que se poderia esperar. Por exemplo, o Concorde conseguiu resolver exatamente uma instância de 85.900 pontos , partes das quais se parecem com isso:

No entanto, algumas instâncias de TSP levam muito tempo, mesmo para o Concorde. Por exemplo, ninguém foi capaz de resolver essa instância de 100.000 pontos com base na Mona Lisa . (Há um prêmio de US $ 1.000 oferecido, se você puder resolvê-lo!)

O Concorde está disponível para download como código-fonte ou executável. Por padrão, ele usa o solucionador de programa linear (LP) embutido QSopt , mas também pode usar melhores solucionadores de LP, como o CPLEX.

O desafio

Qual é a menor instância de TSP que você pode gerar que leva o Concorde a mais de cinco minutos para ser resolvido?

Você pode escrever um programa para gerar a instância ou usar qualquer outro método que desejar.

Pontuação

Quanto menos pontos na instância, melhor. Os laços serão quebrados pelo tamanho do arquivo da instância (veja abaixo).

estandardização

Computadores diferentes rodam mais rápido ou mais devagar, portanto, usaremos o NEOS Server for Concorde como o padrão de medição para o tempo de execução. Você pode enviar uma lista de pontos no seguinte formulário simples de coordenadas 2D:

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

As configurações que devem ser usadas no NEOS são "dados do Concorde (arquivo da lista xy, norma L2)", "Algoritmo: Concorde (QSopt)" e "Semente aleatória: fixa".

Linha de base

A instância rl1889.tspde 1.889 pontos do TSPLIB leva "Tempo total de execução: 871,18 (segundos)", que é mais de cinco minutos. Se parece com isso:

88 cidades, 341 segundos de execução no NEOS

Em um artigo recente, construímos uma família de instâncias de TSP euclidianas difíceis de resolver. Você pode baixar as instâncias dessa família, bem como o código para gerá-las aqui:

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

A instância da cidade 88 dessa família leva o Concorde no servidor NEOS por mais de 5 minutos. A instância de 178 cidades dessa família já leva mais de um dia para resolver.

77 cidades, tempo médio de execução de 7,24 minutos (434,4 segundos) no NEOS

Estou um pouco atrasado para a festa, mas gostaria de contribuir com uma instância de 77 nós, weruSnowflake77.

Criei essa instância enquanto tentava entender quais características locais e globais impõem uma pressão ascendente sobre a quantidade de tempo que o concorde leva para corresponder ao seu limite inferior melhor com a duração do seu tour mais curto encontrado.

Para construir essa instância, comecei com um gráfico base (13 x 13 quadrados) e introduzi sistematicamente novos pontos ou traduzi pontos antigos, mantendo os ajustes que pareciam fazer o concorde se aprofundar em seus galhos, em média, antes de cortar.

A técnica é semelhante à maneira como um algoritmo genético modifica os circuitos existentes e mantém circuitos mais curtos para a próxima geração de mutações, exceto que o próprio gráfico está sendo modificado e os gráficos mais difíceis de resolver são mantidos. Também é semelhante à maneira como modificamos os gráficos usando relaxações para ajudar a construir bons limites inferiores, exceto que estou indo na direção oposta, modificando um gráfico existente para construir um gráfico com limites inferiores difíceis de encontrar.

No processo, encontrei alguns gráficos menores que levam minutos do concorde para serem resolvidos, mas este é o primeiro pequeno gráfico que descobri que leva o concorde pelo menos 5 minutos.

Com 10 execuções de teste no NEOS usando a semente fixa e o QSopt, o tempo de execução médio foi de 7,24 minutos (434.531 segundos). O tempo de execução mínimo foi de 5,6 minutos (336,64 segundos). O tempo de execução máximo foi de 8,6 minutos (515,80 segundos). Nenhum julgamento foi descartado. Tabela de benchmark completa abaixo:

Resultados de benchmark em 10 execuções:

----------------------------------
| 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 (lista xy, norma 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

Repositório

• URL do Github: https://github.com/LDubya/weruSnowflake77

Arquivos do conjunto de problemas do repositório:

• weruSnowflake77.txt (arquivo de lista xy, norma L2)
• weruSnowflake77.tsp (formato TSPLIB, EUC_2D)

Python 3, 911 cidades, 1418 segundos de tempo de execução no NEOS

O seguinte script Python 3.x gera as coordenadas de 911 cidades. O NEOS levou 1418 segundos para calcular o caminho mais curto de 47739.

Aqui está uma foto do seu caminho mais curto (graças a A. Rex):

O código / algoritmo é baseado na bifurcação de Feigenbaum , que eu usei para gerar uma série de valores, que usei como base para gerar as coordenadas das cidades. Eu experimentei os parâmetros até encontrar várias cidades abaixo de 1000 que levaram o NEOS a uma quantidade surpreendente de tempo (bem acima dos 5 minutos necessários).

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: Eu tenho um script em execução em busca de um número menor de cidades que também levam mais de 5 minutos no NEOS. Vou postá-los nesta resposta, se encontrar algum.

PS: Droga! A execução desse script com o parâmetro l 1811 em vez de 1301 resulta em 1156 cidades com um tempo de execução no NEOS de pouco mais de 4 horas , o que é muito mais do que outros casos com parâmetros semelhantes ...