Home > Informatik > Optimierungsprobleme

TSP, Brut force-Methode

Eine brutale Methode, die aber den kürzsten Weg findet.

Solange die Zahl der Städte klein ist, führt die direkte Methode zum kürzesten Weg: Man probiert systematisch alle möglichen Touren aus und wählt dann die kürzeste.

Hier eine Demonstration für N = 5, also für fünf Städte:

Beschreibung siehe folgenden Text

Fünf verschiedene Touren für fünf Städte
Autor: Ulrich Helmich, Lizenz: siehe Seitenende

Hier sehen wir vier verschiedene Touren für N=5, und im nächsten Bild noch vier weitere:

Beschreibung siehe folgenden Text

Noch weitere vier verschiedene Touren für fünf Städte
Autor: Ulrich Helmich, Lizenz: siehe Seitenende

Es gibt noch eine ganze Reihe weiterer möglicher Touren, am besten stellt man alle Touren in Form eines Baums dar:

Beschreibung siehe folgenden Text

Darstellung aller möglichen Touren bei fünf Städten
Autor: Ulrich Helmich, Lizenz: siehe Seitenende

Systematisierung

Die Anzahl der möglichen Touren steigt mit der Zahl der Städte N an.

Beschreibung siehe folgenden Text

Je mehr Städte, desto mehr mögliche Touren, Teil 1
Autor: Ulrich Helmich, Lizenz: siehe Seitenende

Beschreibung siehe folgenden Text

Je mehr Städte, desto mehr mögliche Touren, Teil 2
Autor: Ulrich Helmich, Lizenz: siehe Seitenende

Hier sehen wir die Touren bzw. die zu berechnenden Strecken für N = 2, N = 3 und N = 4. Wenn man die Richtung der Touren nicht berücksichtigt, kommt man bei 4 Städten auf 6 Touren. Der TSP-Algorithmus muss jedoch nur 3 Strecken berechnen, da sich je zwei Touren nur durch die Richtung der Rundreise unterscheiden.

Die folgende Tabelle zeigt die Anzahl der zu berechnenden Strecken S in Abhängigkeit von der Zahl der Städte:

N S
3 1
4 3
5 12
6 60
7 360
8 2.520
9 20.160
10 181.440

Man sieht dann, dass hier folgender Zusammenhang zwischen S und N gilt:

S = (N-1)! / 2

extrem hohe Rechenzeit

Angenommen, ein schneller Rechner kann 1 Million Berechnungen pro Sekunde anstellen, wenn er die kürzeste Rundreise berechnet. Das Problem mit 10 Städten hat er dann in 0,18 Sekunden gelöst. Für 11 Städte braucht er dann 10 mal so lange (N - 1 mal), also knapp 2 Sekunden. Für 12 Städte benötigt der Rechner dann schon 11 mal so lange, also 22 Sekunden, für 13 Städte 4,4 Minuten, für 14 Städte knapp eine Stunde, für 15 Städte 13 Stunden und für 16 Städte mehr als 8 Tage.

Sie sehen, wohin das führt? Die Rechenzeit steigt mit N nicht nur exponentiell, was schon schlimm wäre, sondern fakultativ. Selbst wenn der Rechner, von dem wir eben geredet haben, 100 mal so schnell wäre, so brächte er für 17 Städte immer noch 1,3 Tage, und für 18 Städte 22 Tage, wäre also im Grund nicht viel effektiver als der 100 mal so langsame Rechner.

Die Brute force-Methode, die alle möglichen Strecken berechnet und dann die kürzeste davon wählt, funktioniert also nur bei sehr kleinen Städtezahlen.

Daher hat man Algorithmen entwickelt, die nicht unbedingt die absolut kürzeste Strecke ermitteln, sondern eine "vernünftig" kurze Strecke, deren Rechenzeit dafür aber nicht so extrem fakultativ mit der Anzahl der Städte anwächst.

Eine der bekanntesten und am leichtesten zu implementierende Methode, um eine "vernünftig kurze" Rundreise zu berechnen, ist die "Nearest neighbour"-Methode, die auf der nächsten Seite erläutert wird.

Seitenanfang -
weiter mit der Nearest-neighbour-Methode