sfondo

Il problema del commesso viaggiatore (TSP) richiede il circuito più corto che visita una determinata collezione di città. Ai fini di questa domanda, le città saranno punti nel piano e le distanze tra loro saranno le solite distanze euclidee (arrotondate al numero intero più vicino). Il circuito deve essere "andata e ritorno", nel senso che deve tornare alla città di partenza.

Il risolutore Concorde TSP è in grado di risolvere casi del problema del commesso viaggiatore euclideo, esattamente e molto più velocemente di quanto ci si aspetterebbe. Ad esempio, Concorde è stato in grado di risolvere esattamente un'istanza di 85.900 punti , parti delle quali assomigliano a questa:

Tuttavia, alcune istanze di TSP impiegano troppo tempo, anche per Concorde. Ad esempio, nessuno è stato in grado di risolvere questa istanza di 100.000 punti basata sulla Gioconda . (C'è un premio di $ 1.000 offerto se puoi risolverlo!)

Concorde è disponibile per il download come codice sorgente o eseguibile. Per impostazione predefinita, utilizza il solutore QSopt del programma lineare (LP) incorporato , ma può anche utilizzare solutori LP migliori come CPLEX.

La sfida

Qual è l'istanza TSP più piccola che puoi generare che impiega Concorde a superare i cinque minuti ?

È possibile scrivere un programma per generare l'istanza o utilizzare qualsiasi altro metodo desiderato.

punteggio

Meno punti nell'istanza, meglio è. I legami verranno interrotti dalla dimensione del file dell'istanza (vedi sotto).

Standardizzazione

Computer diversi funzionano più velocemente o più lentamente, quindi utilizzeremo il server NEOS per Concorde come standard di misurazione per il runtime. Puoi inviare un elenco di punti nel seguente semplice modulo di coordinate 2D:

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

Le impostazioni che dovrebbero essere utilizzate su NEOS sono "Dati Concorde (file elenco xy, norma L2)", "Algoritmo: Concorde (QSopt)" e "Seme casuale: fisso".

Baseline

L'istanza di 1.889 punti rl1889.tspdi TSPLIB richiede "Tempo di esecuzione totale: 871.18 (secondi)", che è più di cinque minuti. Sembra così:

88 città, 341 secondi di autonomia su NEOS

In un recente articolo abbiamo costruito una famiglia di istanze TSP euclidee difficili da risolvere. Puoi scaricare le istanze da questa famiglia e anche il codice per generarle qui:

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

L'istanza di 88 città di questa famiglia porta Concorde sul server NEOS per più di 5 minuti. L'istanza di 178 città di questa famiglia richiede già più di un giorno per essere risolta.

77 città, 7,24 minuti (434,4 secondi) tempo di esecuzione medio su NEOS

Sono un po 'in ritardo alla festa, ma vorrei contribuire con un'istanza a 77 nodi, weruSnowflake77.

Ho creato questa istanza mentre cercavo di capire quali caratteristiche locali e globali impongono una pressione al rialzo sulla quantità di tempo impiegata dalla concorde per abbinare il suo limite inferiore migliore con la durata del tour più breve trovato.

Per costruire questa istanza, ho iniziato con un grafico di base (13 x 13 quadrati), quindi ho introdotto sistematicamente nuovi punti o tradotto vecchi punti, mantenendo le regolazioni che sembravano consentire alla concorde di approfondire i suoi rami in media prima di tagliare.

La tecnica è simile al modo in cui un algoritmo genetico muta i tour esistenti e mantiene i tour più brevi per la prossima generazione di mutazioni, tranne per il fatto che il grafico stesso viene mutato e vengono mantenuti i grafici più difficili da risolvere. È anche simile al modo in cui mutiamo i grafici usando i rilassamenti per aiutare a costruire buoni limiti inferiori, tranne che sto andando nella direzione opposta, mutando un grafico esistente per costruire un grafico con limiti inferiori difficili da trovare.

Nel processo ho trovato alcuni grafici più piccoli che impiegano minuti concorde per risolversi, ma questo è il primo piccolo grafico che ho trovato che impiega concorde un minimo di 5 minuti.

Con 10 esecuzioni di prova su NEOS con seed fisso e QSopt, l'autonomia media è stata di 7,24 minuti (434,531 secondi). La durata minima è stata di 5,6 minuti (336,64 secondi). Il tempo di esecuzione massimo è stato di 8,6 minuti (515,80 secondi). Nessun processo è stato scartato. Tabella di riferimento completa di seguito:

Risultati benchmark su 10 serie:

----------------------------------
| 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 (elenco 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

deposito

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

Problema impostare i file dal repository:

• weruSnowflake77.txt (file elenco xy, norma L2)
• weruSnowflake77.tsp (formato TSPLIB, EUC_2D)

Python 3, 911 città, 1418 secondi di tempo di esecuzione su NEOS

Il seguente script Python 3.x genera le coordinate di 911 città. NEOS ha richiesto 1418 secondi per calcolare il percorso più breve di 47739.

Ecco una foto del tuo percorso più breve (grazie ad A. Rex):

Il codice / algoritmo si basa sulla biforcazione di Feigenbaum , che ho usato per generare una serie di valori, che ho usato come base per generare le coordinate delle città. Ho sperimentato i parametri fino a quando non ho trovato un numero di città con meno di 1000 che hanno impiegato NEOS a una quantità di tempo sorprendente (ben al di sopra dei 5 minuti richiesti).

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: ho uno script in esecuzione alla ricerca di un numero inferiore di città che impiegano anche> 5 minuti su NEOS. Li posterò in questa risposta se ne trovo qualcuno.

PS: Accidenti! L'esecuzione di questo script con il parametro l 1811 anziché 1301 comporta 1156 città con un tempo di esecuzione su NEOS di poco più di 4 ore , che è molto più di altri casi con parametri simili ...