Bei dem hier betrachteten Traveling-Salesman-Problem geht es darum, eine möglichst kostengünstige Rundreise durch eine gegebene Menge an “Städten” (ich werde bei der Terminologie “Stadt” bleiben) zu finden, wobei jede Stadt genau 1 Mal besucht werden muss. Jede Wegstrecke zwischen 2 Städten ist mit bestimmten Reisekosten verbunden. In dem von mir gemeinten Fall des metrischen TSP entsprechen die Reisekosten genau der Luftlinie zwischen den beiden Städten. Daher habe ich die Städte der Einfachheit halber als Punkte in der Ebene modelliert (mit einer X- und einer Y-Koordinate), womit bereits erste Experimente möglich sind.

Phase 1: Reduktion auf den Trivialfall des TSP

TSP - Trivialfall mit nur 3 Städten

Mein Algorithmus greift darauf zurück, dass das Rundreiseproblem für 3 Städte trivial ist, weil es nur 1 mögliche Rundreise durch 3 Städte gibt (siehe Grafik auf der rechten Seite).

Bei 1-3 Städten kann der Algorithmus daher direkt die Lösung zurückgeben, weil sie offensichtlich ist.

Bei mehr als 3 Städten arbeitet der Algorithmus in 2 Phasen.

In der 1. Phase werden die gegebenen Städte solange gefaltet, bis nur noch 3 Städte übrig sind.

Es werden jeweils 2 Städte gefaltet. Das sieht so aus, dass eine neue fiktive Stadt erzeugt wird, deren Koordinate gleich dem Mittelpunkt/Zentrum der 2 gefalteten Städte ist. Die 2 gefalteten Städte werden dann durch die neue fiktive Stadt ersetzt, wobei sich die fiktive Stadt ihre “Vorbilder” (“Kind-Städte”) merkt. Dadurch wird das Falten zugleich umkehrbar.

Eine naive Implementierung sieht zum Beispiel so aus, dass in jedem Schritt zufällig eine Stadt ausgewählt und ihr nächster Nachbar berechnet wird. Diese beiden Städte werden dann gefaltet. Der Vorgang wird so lange wiederholt, bis wie gesagt nur noch 3 Städte übrig sind. Fiktive Städte können genauso gefaltet werden wie die Ursprungs-Städte. (Dadurch ergibt sich je nach Anzahl der Städte eine beliebig tiefe “Verschachtelung”.)

Phase 2: Entfalten der Städte mit optimaler Integration der Kind-Städte

Nach der 1. Phase sind wir also beim Trivialfall mit 3 Städten angekommen. Das ist auch schon unsere vorläufige Lösung bzw. die vorläufige Rundreise.

In der 2. Phase werden die fiktiven Städte wieder entfaltet, wobei die vorläufige Rundreise bei jedem Schritt erhalten wird.

TSP - Fiktive Stadt (blau) mit Kind-Städten (rot) in einer vorläufigen Rundreise zu Beginn von Phase 2

Betrachten wir die Grafik auf der rechten Seite. Nehmen wir an die beiden rot markierten Städte seien die Kind-Städte der blau markierten fiktiven Stadt. (Wie man auch gut sehen kann befindet sich die blaue Stadt genau im Zentrum ihrer beiden Kind-Städte.)

Wenn die fiktive Stadt nun in Phase 2 durch ihre Kinder ersetzt wird, dann gibt es genau 2 Möglichkeiten, wie man die beiden Kind-Städte in die gegebene Rundreise integrieren kann. Dazu muss man sich die blaue Stadt wegdenken, denn diese existiert dann ja nicht mehr.

TSP - Entfalten mit beiden Integrationsmöglichkeiten (grün = die bessere Variante)

Auf dem nächsten Bild sind die beiden Möglichkeiten eingezeichnet. Die grüne Variante ist offensichtlich die kürzere und damit auch die bessere Wahl.

Halten wir fest: Beim Entfalten muss der Algorithmus nach jedem Schritt entscheiden, wie er die neuen Städte in die bestehende Rundreise integriert. Dabei gilt es zwischen genau 2 Alternativen zu wählen… und das ist relativ leicht.

Phase 2 endet, wenn keine fiktiven Städte mehr übrig sind, die noch entfaltet werden könnten. Die Rundreise ist damit “fertig” und kann vom Algorithmus zurückgegeben werden.

Namensgebung: RFA

Weil der Algorithmus auf dem Falten & Entfalten der Städte beruht taufe ich ihn RFA: Rekursiver-Falt-Algorithmus bzw. recursive-fold-algorithm.

Beispiele

TSP - Rundreise mit 100 Städten

TSP - Rundreise mit 500 Städten

Die Rundreise auf der linken Seite besteht aus 100 Städten und wurde im Bruchteil einer Sekunde berechnet.

Die Rundreise auf der rechten Seite besteht aus 500 Städten und wurde in nur etwas mehr als 1 Sekunde berechnet.

Wie man an den beiden Beispielen auch gut sehen kann arbeitet der RFA keineswegs optimal, denn an der einen oder anderen Stelle überschneiden sich die Rundreisen sogar (das sicherste Zeichen dafür, dass eine Lösung suboptimal ist).

Nichtsdestotrotz handelt es sich in beiden Fällen um sehr gute Näherungslösungen, die zudem in kürzester Zeit berechnet wurden.

Performanz & Güte des RFA

Der RFA befindet sich, was die Laufzeit betrifft, in der Komplexitätsklasse O(n²)¹ (Faustregel: Verdoppelt man die Anzahl der Städte, so braucht der Algorithmus 4 Mal so lang). Die Speicherkomplexität liegt dagegen bei O(n).

In allen mir bekannten Fällen stellten die vom Algorithmus erzeugten Rundreisen eine gute bis sehr gute Näherung an die optimale Lösung dar.

Dank seiner überragend hohen Geschwindigkeit eignet sich der RFA in meinen Augen besonders für die Berechnung von Näherungslösungen bei sehr großen Probleminstanzen mit vielen tausenden Städten. Für eine Rundreise durch 10000 Städte *klick* benötigt meine eigene, sehr simple Python-Implementierung beispielsweise ca. 7 Minuten und 20 Sekunden. Gemessen an der Qualität der erhaltenen Näherungslösung ist das ziemlich schnell.

Ausgehend von dieser Näherungslösung kann die Rundreise dann Stück für Stück durch weitere Algorithmen dem Optimum näher gebracht werden.

Zum Vergleich möchte ich außerdem an meinen evolutionären Algorithmus für das TSP erinnern (habe ich damals ebenfalls in Python implementiert). Dieser brauchte bei Städtezahlen jenseits der 100 bereits ewig für eine Näherungslösung. (Für weitere Details siehe Projekte -> Lernleistung.)

Testlauf mit TSP-Instanzen der TSPLIB

Für TSP – Testläufe gibt es die sogenannte TSPLIB. Sie enthält dutzende von TSP-Instanzen mit den unterschiedlichsten Eigenschaften. Von kleinen bis sehr großen Städte-Zahlen ist alles dabei. Das besondere ist, dass in der TSPLIB in vielen Fällen die optimale Lösung bereits enthalten ist. Damit kann man die Ergebnisse von TSP-Algorithmen überprüfen oder ihre Güte in der Praxis abschätzen.

Bisher habe ich meinen Algorithmus zwar hoch gelobt, aber ich bin glaubwürdige Aussagen schuldig geblieben. Daher habe ich ihn auf einige metrische TSP-Instanzen der TSPLIB angesetzt (Quelle):

Im Schnitt sind die von meinem Algorithmus berechneten Rundreisen 119.14% länger als die jeweilige optimale Rundreise.

Damit schlägt sich der RFA bei deutlich besserer Laufzeitkomplexität mindestens genausogut wie die Christofides-Heuristik bzw. der Christofides-Näherungsalgorithmus (mit einer Laufzeitkomplexität von O(n³)). Die Christofides-Heuristik hat nämlich für metrische Rundreiseprobleme eine feste Gütegarantie von 50%, d.h. sie garantiert einen Faktor von höchstens 150%, d.h. die Lösungen sind maximal 1,5fach so lang wie die optimale Lösung. (Sie ist damit der bisher beste Algorithmus mit einer festen Gütegarantie.)

Zwar kann ich (noch?) nicht beweisen, dass der RFA ebenfalls über eine Gütegarantie verfügt. Aber in der Praxis zeigt sich, dass der Faktor deutlich unter 150% bleibt.

Übertragbarkeit auf nicht-metrische Rundreiseprobleme

Der RFA ist zwar auch übertragbar auf nicht-metrische Rundreiseprobleme (das Falten von 2 “Städten” muss man dann entsprechend neu erfinden), allerdings erhoffe ich mir davon keine so guten Resultate. Der RFA beruht nunmal hauptsächlich auf der Dreiecksungleichung (denn für je 2 “Städte” muss eine Art fiktive Stadt im Zentrum der 2 Städte konstruierbar sein). Je stärker diese verletzt wird, desto schlechter werden die Ergebnisse vermutlich sein. Daher eignet sich der RFA auch nur bedingt für asymmetrische TSP-Instanzen (also wenn die Reisekosten für A -> B nicht immer auch den Reisekosten B -> A entsprechen (bspw. bergauf vs. bergab)).

Ein dahingehender Test meinerseits steht aber noch aus.

Verbesserungsmöglichkeiten

Abgesehen von der Art der Implementierung (bis jetzt nur in Python; viel schneller wäre C++) kann man den Algorithmus selbst, d.h. seine Laufzeitkomplexität, definitiv noch weiter verbessern.

Ich sehe großen Spielraum in Phase 1 beim Falten der Städte. Die wesentliche Rechenleistung in Phase 1 besteht darin, zu einer gegebenen Stadt ihren nächsten Nachbarn zu finden. Das kann man deutlich beschleunigen, indem man die Städte zu Beginn von Phase 1 partitioniert (die “Landkarte” wird auf bestimmte Weise in Quadrate aufgeteilt). Dadurch muss man beim Suchen des nächsten Nachbars nicht mehr alle Städte berücksichtigen, sondern nur noch diejenigen Städte, die sich in den umliegenden/benachbarten Partitionen befinden. Beim Falten von 2 Städten muss dann natürlich sichergestellt werden, dass die neu erzeugte fiktive Stadt ihrerseits in die korrekte Partition eingeordnet wird.

Die Güte des Algorithmus kann man womöglich deutlich verbessern, indem man eine Methode entwickelt, die auf intelligente Weise die Städte faltet. In meiner naiven Implementierung geschieht die Auswahl der zu faltenden Städte nämlich zufällig. An dieser Stelle kann man gewiss noch Verbesserungen erzielen, indem man die Reihenfolge des Faltens nicht nur dem Zufall überlässt.

In Phase 2 sehe ich wenig Potenzial zur Verbesserung, weil das Entfalten – wie beschrieben – quasi optimal erfolgt. Die Reihenfolge des Entfaltens spielt jedoch mMn. wenigstens eine untergeordnete Rolle, deshalb behalte ich mir eine nähere Untersuchung von Phase 2 vor.

Zusammenfassung

Der von mir entwickelte Algorithmus für das metrische TSP hat eine Laufzeitkomplexität von O(n²) und eine Speicherkomplexität von O(n). Weil er auf dem Falten & Entfalten der Städte beruht und das TSP dabei (zumindest zwischenzeitlich) auf den Trivialfall reduziert, nenne ich ihn RFA: Rekursiver-Falt-Algorithmus.

Obwohl meine Python-Implementierung ausgesprochen naiv vorgeht und ich mir kaum Mühe gegeben habe effizienten Code zu schreiben, bewältigt sie TSP-Instanzen der TSPLIB in sehr kurzer Zeit. Die Länge der dabei gefundenen Lösungen lag im Durchschnitt nur ca. 19% über der jeweils optimalen Lösung (also Faktor 119%; der höchste Faktor betrug 130%).

Daher kann der RFA durchaus mit der Christofides-Heuristik – der bisher beste Algorithmus mit einer festen Gütegarantie für das metrische TSP – konkurrieren, nicht zuletzt weil diese eine deutlich schlechtere Laufzeitkomplexität von O(n³) besitzt (und überdies auch noch sehr viel komplizierter ist). Eventuell kann ich beweisen, dass auch für den RFA eine feste Gütegarantie gilt. In der Praxis schlägt er sich auf alle Fälle sehr gut.

Der RFA ist zwar grundsätzlich auch übertragbar auf nicht-metrische Rundreiseprobleme, allerdings hängt die Güte des RFA sehr wahrscheinlich von der Dreiecksungleichung ab. Je stärker diese verletzt wird, desto schlechter werden die Ergebnisse vermutlich sein.

Dank seiner überragenden Geschwindigkeit eignet sich der Algorithmus in meinen Augen besonders für die Berechnung von Näherungslösungen für sehr große TSP-Instanzen mit vielen Tausend Städten.

Download meiner Python-Implementierung

RFA_demo.zip (2.2 MB)

Der Quelltext befindet sich im Ordner “src” (die Dateien sind UTF-8-kodiert). Die im Artikel verwendeten TSPLIB-Challenges (und viele weitere) befinden sich im Ordner “TSPLIB”.

Die auszuführende Datei ist src/RFA_demo.py. Ich habe Python 2.6 verwendet, es sollte aber auch mit Python 2.5 laufen.

In der Datei RFA_demo.py kann man auch einige Einstellungen verändern. Ich habe die entsprechenden Stellen deutlich hervorgehoben und jede Einstellung in Deutsch beschrieben (ansonsten ist alles in Englisch gehalten). Sogar Laien haben also eine faire Chance die Demonstration auf ihrem PC auszuführen.

Viel Spaß damit!

Traut ihr euch?

Dies ist die kurze Fassung dessen, was viele vermeintliche Computerexperten bei fast jeder Gelegenheit predigen. Ich bin zuerst selbst darauf reingefallen und bin Anfang 2006 von Windows auf Ubuntu (eine Linux-Distribution) umgestiegen. Windows war von da an etwa 1 Jahr lang nur noch ein Zweitsystem zum Spielen.

Hinweis: Diese Abrechnung bezieht sich ausschließlich auf Linux-Systeme, die auf (privaten) Workstations ihren Einsatz finden! Auf Servern ist Linux meiner Meinung die erste Wahl (auch wenn meine Kritik teilweise auch auf “Server-Linuxe” übertragen werden kann)!

Behauptung: Linux ist ein grauenvolles Frickelsystem

Irgendwann gab meine Festplatte den Geist auf und ich musste das System komplett neu aufsetzen. Dazu hatte ich dann aber keine Lust mehr, weil Linux schier unendlich viel Zeit gefressen hatte, bis es vollständig eingerichtet war und alles so lief, wie es sollte. Das ist auch heute noch mein Hauptkritikpunkt: Linux ist ein grauenvolles Frickelsystem. Auch Ubuntu ist da nicht anders, obwohl es überall heißt, dass es ja ach so benutzerfreundlich wäre.

Die Betonung liegt auf grauenvoll, weil es nicht nur ein Frickelsystem ist, sondern eben auch noch ein besonders schlimmes bzw. schlecht gemachtes Frickelsystem. Damit meine ich vor allem, dass die Konfigurationsdateien (in denen z.B. das Verhalten der Programme festgelegt wird) aller größeren Programme/Daemons sich bezüglich ihres Formats/ihrer Syntax voneinander unterscheiden. Jedes dieser Programme muss demzufolge auch selbst – auf eigene Faust – seine Konfigurationsdateien auslesen, was eine gewaltige Fehlerquelle darstellt. Und wer bitte schön hatte zum Beispiel bei Linux noch nie das Problem, dass eine Konfigurationsdatei laut offizieller Anleitung/Dokumentation korrekt ist, aber irgendwie doch nicht funktioniert? Eben, das tritt nämlich fast immer auf. Manchmal steckt dahinter auch ein Fehler, den man selbst zu verantworten hat. Das ist aber letztendlich in den meistne Fällen nur eine Folge der viel zu komplizierten Konfigurationsdateien (Syntax zu komplex, zu wenig fehlertolerant etc.).

Wie man es besser machen könnte? Da, wo es angemessen und praktikabel ist, ein einheitliches Format einführen (für dieses Format muss dann auch nur 1x Code geschrieben werden => zentral => bessere Wartbarkeit und weniger Bugs). Beispielsweise eines wie das intuitive INI-Format (oder ein ähnliches):

[SEKTION]
name=wert
name2=anderer_wert

Größere Daemons, die tatsächlich noch mehr brauchen, dürfen gerne auch komplexere Formate für ihre Konfigurationsdateien definieren. Aber bitte, ihr Linux-Freaks, gebt nicht mehr jedem Kleinst-Daemon sein eigenes verdammtes Konfigurationsformat!
Das führt nämlich dazu, dass man für jede etwas größere Konfigurationsänderung Manuals, Tutorials und Internetforen durchkämmen muss, bis es dann – meist nach Stunden – endlich klappt.

Kritik: Linux gebe dem Anwender sehr viel mehr “Macht” als Windows

Ein PRO-Argument für Linux lautet, dass man unter Linux – durch den berüchtigten root-Account – sehr viel mehr Einfluß auf sein System hat. Man kann sehr viel genauer bestimmen, was es macht und wie es das macht.
Das stimmt auch. Allerdings werte ich das größtenteils nicht als Vorteil:

1. Linux ist ein Frickelsystem (siehe oben) und man kann von dem root-Account nicht profitieren ohne sich zunächst (in jeder Angelegenheit aufs Neue) in komplizierte Details einzuarbeiten.
2. Es gibt nur ganz wenige Fälle in denen man unter Linux etwas machen kann, was unter Windows nicht auch (mit geringerem Aufwand) so oder so ähnlich möglich wäre. Das sind dann meistens auch nur Spielereien, auf die man auch gut und gerne ganz verzichten kann.

Es gibt natürlich Momente in denen man vom mächtigen root-Account profitiert. Aber auch hier muss man sich erst mühsam in Details einarbeiten.

Absolut vernachlässigt werden bei Linux Benutzer, die entweder nicht oder kaum dazu in der Lage (wg. zu hohem Alter o.ä.) sind oder keine Lust darauf haben, sich so (unangemessen) viel Fachwissen anzueignen. Das äußert sich darin, dass vieles unter Linux nicht anders zu meistern ist als durch einen Umweg über die Konsole (Shell). Dann tippt man mehr oder weniger viele Befehle ein, die jeweils eine eigenen “Befehlssatz” aufweisen und man hat erreicht, was man erreichen wollte (zum Beispiel das Killen eines Programms). Es gibt zwar immer wieder Ansätze – gerade für Windows-Abwanderer – sich an Windows anzunähern, z.B. durch das Bereitstellen von Programmen, die Windows-Programmen ähnlich sehen (Taskmanager und ähnliches). Meine Erfahrung ist aber, dass diese Programme extrem unzuverlässig sind. Der Schwerpunkt wird bei Linux nunmal nach wie vor auf die Konsolenprogramme gelegt.

Kritik: Linux hat viele Probleme mit Hardware

Ob es daran liegt, dass die Hersteller keine Treiber bereitstellen oder nicht… es ist mir letztlich egal, was die Ursachen dafür sind und wer daran Schuld ist. Am Ende kommt es doch nur darauf an, was ein System kann und was es nicht kann. Und dazu gehört auch die (schnellstmögliche) Erkennung und Nutzung von neuer Hardware. Hier kommt Linux gar nicht gut weg.

Windows ist hier jedoch – wegen seiner Marktführerschaft – ganz klar an der Spitze. Man schließt die neue Hardware einfach an und meistens ist sie innerhalb weniger Sekunden voll einsatzbereit. Unter Linux muss man stattdessen häufig auf irgendwelche Arten improvisieren – das schließt meist auch wieder das Anlegen/Anpassen komplizierter Konfigurationsdateien ein -, um Hardware zu nutzen, die nicht auf Anhieb erkannt werden kann (und davon gibt es nicht wenig).

Das ist auch ein Punkt, der mich schließlich dazu bewegt hat, wieder zu Windows zurückzuwechseln. Unabhängig davon, ob es in der Macht der Linux-Entwickler steht, an der Hardware-Erkennung etwas wesentlich zu verbessern oder (mangels fehlender Kooperation der Hardware-Hersteller) nicht.

Widerspruch: Windows sei unsicher(er als Linux)

Ich kann mich nicht daran erinnern, wann ich mit Windows das letzte Mal Probleme mit Viren/Trojanern/Würmern o.ä. hatte. Zugegeben, ich habe zu XP-Zeiten zum Surfen und normalen Arbeiten ein eingeschränktes Benutzerkonto verwendet. Mein System so einzurichten hat mich aber nur ein paar Minuten Zeit gekostet…
Natürlich hatte ich auch eine Firewall und ein Antiviren-Programm installiert. Das ist aber auch Pflicht bei Windows: Es ist schließlich das mit großem Abstand am weitesten verbreitete System.

Ich kann mich übrigens genausowenig daran erinnern, wann mein Windows das letzte Mal abgestürzt ist…

Ein paar Worte zu Windows Vista

Ich nutze Vista erst seit wenigen Tagen, aber mein erster Eindruck ist, dass es ein sehr mächtiges und modernes Betriebssystem ist. Viele Dialoge und v.a. die Navigation wurden im Vergleich zu Windows XP aufgebessert. Leider wird Windows Vista in einem sehr besch… Konfigurationszustand ausgeliefert. So frisst zum Beispiel die Systemwiederherstellung unglaublich viel Leistung; nachdem ich sie deaktiviert habe, läuft mein System viel flüssiger. Außerdem habe ich mit Hilfe von Tuneup Utilities viele unnötige Dienste deaktiviert oder “gedrosselt”.
Zugegeben: Im “Auslieferungszustand” ist Vista unerträglich (meiner Meinung nach). Man kann aber auch dieses Windows innerhalb weniger Stunden in ein schnelles, sparsames und modernes System umwandeln. Dazu braucht es unter Windows auch keine komplizierten Konfigurationsdateien…

Schlusswort

Mir ist klar, dass die Mehrheit der “Experten” anderer Meinung ist. Diese Mehrheit ist auch dazu aufgerufen mir zu widersprechen und mich zu widerlegen. Letztlich ist es aber immer eine subjektive Entscheidung, wenn es darum geht, welches Betriebssystem man lieber verwendet. Daher habe ich mich in diesem Artikel auf die Aspekte konzentriert, die m.E. ganz objektive Schwächen von Linux darstellen oder Falschaussagen über Windows sind.

Bevor man mit mir eine Diskussion darüber anfängt, sollte man sich aber bitte einmal ehrlich fragen, wie viel Zeit man mit dem Konfigurieren seines Linux-Systems verbracht hat und wie viel Zeit unter Windows für die Konfiguration aufgewendet werden musste und was letztlich weniger nervenaufreibend war. Es sollte ja klar sein, was meine persönliche Antwort darauf ist…

Bitte – liebe Linux-Anhänger – zerreißt mich nicht gleich in der Luft sondern versucht erst einmal ungefähr zu verstehen, was mir an Linux stinkt…

Auch ich bin dankbar dafür, dass es so viele kluge Menschen gibt, die unentgeltlich sehr viel Arbeit in ein kostenloses – sogar quelloffenes – Betriebssystem stecken. Mit diesem Beitrag möchte ich aber unter anderem auch aufzeigen, dass Linux keineswegs perfekt ist und dass man den einfachen Leuten, die sich nicht so sehr auskennen, besser vermitteln muss, auf was sie sich mit Linux einlassen, wenn sie sich dafür entscheiden. Momentan gebärdet sich die Linux-Gemeinde aber eher so, wie eingangs erwähnt: “Linux ist das größte, das schnellste, das schönste, das sicherste und das beste!” Dazu kommen natürlich noch viele Seitenhiebe gegen Microsoft/Windows. Gegen dieses Gehabe wendet sich mein Artikel in erster Linie… von einem Betriebssystem, das so gefeiert wird, habe ich schlicht und ergreifend mehr erwartet, als mir letzlich geboten wurde.

Durch Zufall bin ich nämlich auf OpenID gestoßen, ein Single Sign-on-System, das ziemlich genau einem System entspricht, an dessen Entwicklung ich selbst schon gearbeitet habe und das dasselbe Ziel hat: Das Problem der vielen Accounts/Logins auf etlichen verschiedenen Webseiten zu lösen…

Das würde mich ja gar nicht stören (bis auf die Arbeit, die ja jetzt quasi umsonst war, weil der OpenID-Standard sich offenbar bereits durchgesetzt hat), wenn da nicht noch dieser andere Vorfall wäre:
Als ich vor kurzem eine Variante des Transportproblems lösen musste, ist mir ein schier genialer Algorithmus eingefallen, der bereits verdammt gute Näherungslösungen und in den meisten Fällen sogar optimale Ergebnisse lieferte. Damals wusste ich gar nicht, dass das Problem in der Wissenschaft bereits abgehandelt wurde und ich wusste auch nicht, dass es “Transportproblem” genannt wird. Aber es handelt sich in der Tat um eine Variante des eigentlichen Problems (für die, die es interessiert: eine Lagerstätte/Quelle kann bei dieser Variante immer nur genau eine Ware liefern und somit nur einen Bedarf decken). Dennoch: Der Algorithmus, den ich entwickelt habe, entspricht der Vogelschen Approximationsmethode… der Ansatz, der dahinter steckt, den gibt es also schon länger.

Fazit: Ich lebe in der falschen Zeit! (Kommt mir auch aus ganz anderen Gründen häufig so vor.)
PS: Den Titel bitte nicht falsch verstehen, ich käme im Leben nicht darauf, irgendwem vorzuwerfen, er hätte mir meine Idee geklaut, nur weil er sie vor mir hatte! Das ist eigentlich eine Selbstverständlichkeit, aber hier lesen ja immer noch Juristen mit und da erkläre ich es lieber nochmal.

Für das sogenannte Traveling-Salesman-Problem soll ich außerdem im Rahmen dieser Lernleistung einen evolutionären Algorithmus schaffen.

Das Traveling-Salesman-Problem

Das Traveling-Salesman-Problem (TSP) ist einfach formuliert: Ein Handlungsreisender muss n Städte besuchen und am Ende zu seinem Ausgangsort zurückkehren. Gesucht ist die kürzeste Rundreise.

Viele schlaue und dumme Menschen haben sich auf der Suche nach einem effizienten Algorithmus jahrzehntelang den Kopf darüber zerbrochen. Einen Ansatz stellen die sogenannten evolutionären Algorithmen dar, die die Evolution als Vorbild haben.

Was ist ein evolutionärer Algorithmus?

Zitat Wikipedia:

“Ein Evolutionärer Algorithmus (EA) ist ein Optimierungsverfahren, das als Vorbild die biologische Evolution hat.”

Prinzipiell prozessiert ein evolutionärer Algorithmus eine Population mit n Individuen nach dem Vorbild der Evolution: “survival of the fittest”. Jedes Individuum stellt eine mögliche Lösung des jeweiligen Problems dar. Im Falle des TSP entspricht also jedes Individuum einer möglichen Rundreise.

Im Laufe des Algorithmus pflanzen sich außerdem je zwei Individuen fort und erzeugen ein Kind-Individuum nach Vorbild der Natur mittels Rekombination. Zusätzlich finden – ebenfalls nach Vorbild der Natur – mit einer bestimmten Wahrscheinlichkeit Mutationen statt, also z.B. (normalerweise) zufällige Veränderungen der Route.

Jeder Durchlauf eines evolutionären Algorithmus’ sieht also mehr oder weniger so aus:

• Entferne x Individuen aus der Population. (Zum Beispiel die beiden schlechtesten Routen.)
• Rekombiniere x-Mal zwei Individuen aus der Population. (Zum Beispiel die beiden besten Routen.)
• Wende mit einer bestimmten Wahrscheinlichkeit eine Mutation auf die Individuen an. (Zum Beispiel mit einer Wahrscheinlichkeit von 15%.)
• Wenn die maximale Anzahl von Durchläufen (Generationen) erreicht ist, beende den Vorgang, ansonsten starte einen neuen Durchlauf.

Die Güte bzw. Qualität eines evolutionären Algorithmus hängt vor allem von folgenden Faktoren ab:

• Populationsgröße
• Rekombinationsmethode
• Mutationsmethode
• Mutationswahrscheinlichkeit
• …

Ein evolutionärer Algorithmus für das Travelling-Salesman-Problem

Wie oben gesagt ist es meine Aufgabe für das TSP einen evolutionären Algorithmus zu programmieren. Als Programmiersprache habe ich mich für Python und als Entwicklungsumgebung für eclipse mit PyDev entschieden. (Damit lässt sich super arbeiten!)
Mit der Arbeit am evolutionären Algorithmus habe ich heute begonnen, und ich muss sagen: Ich bin bereits jetzt sehr zufrieden. Da die Güte des evolutionären Algorithmus – siehe oben – von vielen Faktoren abhängt, habe ich mich für eine Umsetzung entschieden, bei der ich all diese Faktoren leicht ändern kann.

Das ist mir ganz gut gelungen: Alle Parameter und Komponenten des evolutionären Algorithmus sind ganz einfach austauschbar. (Leider werde ich bis zum Erhalt meines Abiturs keine Quelltexte veröffentlichen. Der menschlichen Dummheit sind einfach keine Grenzen gesetzt und ich könnte mir vorstellen, dass man mir vorwirft, meine Arbeit aus dem Internet von einem “Robert Nitsch” kopiert zu haben.)

Nun folgt der schwierigste, aber wohl auch spannendste Teil meiner besonderen Lernleistung. Ich werde prüfen welche Parameter den besten evolutionären Algorithmus ausmachen und verschiedene Konfigurationen miteinander vergleichen. Natürlich wird auch eine Begründung nicht fehlen – also warum Konfiguration A besser ist als Konfiguration B.

Meine Arbeit und meine Ergebnisse muss ich abschließend in einem Skript dokumentieren und in einer Präsentation vorstellen. Meine Ergebnisse werde ich natürlich auch hier auf meiner Homepage festhalten, damit Schüler, die eine ähnliche Lernleistung erbringen, davon vielleicht profitieren können.

Für Tipps und Ratschläge bezüglich meiner besonderen Lernleistung bin ich natürlich jederzeit offen.

Which Programming Language are You?

Dieser Test wird mir sogar gerecht: mit PHP arbeite ich im Moment am meisten. Vor allem an DS OBST: http://obst-ab.sf.net.

Die Wikipedia beschreibt Hackits übrigens folgendermaßen:

Eine Hacking Challenge (englisch: ‚Herausforderung zum Hacken‘) oder ein Hackit (englisch: ‚Knack es‘) ist eine Aufgabe oder in der Regel eine Abfolge von Aufgaben aus dem Bereich des Hackens, meist geht es um das Eindringen in speziell dafür bereit gestellte passwortgeschützte Bereiche. Solche Aufgaben werden auf speziellen Webseiten für Menschen angeboten, die sich für Computersicherheit interessieren und fördern die spielerische und sportliche Auseinandersetzung mit diesem Themenbereich.

(Quelle: http://de.wikipedia.org/wiki/Hackit, Stand: 04.01.2007)

Nachdem euch jetzt hoffentlich grob bewusst geworden ist, worum es bei einem HackIt geht, möchte ich euch ein gutes Beispiel für ein HackIt geben. Das HackIt, von dem ich rede, heisst “InfoGamE” und ihr könnt es unter http://ighack.info erreichen. Wie man auf der Rangliste sieht habe ich das HackIt mit seinen insgesamt 20 Leveln erfolgreich absolviert (mein Nickname dort ist “bmaker”). Das hat aber – zugegeben – gute 4 Wochen gedauert. Ich glaube sogar es war etwas mehr …

Das InfoGamE ist in jedem Fall ein ganz typisches HackIt. Das erkennt man daran, dass vor allem die ersten und leichteren Levels viel mit Javascript zu tun haben. Man kommt also oft nur dann in das nächste Level, wenn man das Javascript versteht und das Passwort ermitteln kann. Beim InfoGamE kommt jedoch erschwerend hinzu, dass man oft sehr lange rätseln muss und manchmal dauert es Stunden oder sogar mehrere Tage bis man mit Google zu einem Hinweis gekommen ist. Aber gerade das macht auch einen gewissen Reiz aus. Am allerschönsten wird es, wenn man das HackIt gemeinsam mit Freunden durchspielt. Leider war mir “nur” der Wettbewerb mit flüchtigen Internetbekanntschaften vergönnt.