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!

So… es muss jetzt mal raus. Seit Montag haben wir Semesterferien, d.h. es gibt keine Vorlesungen/Übungen mehr und wir bereiten uns jetzt auf die Prüfungen vor. Die erste Prüfung ist Mathematik für Informatiker I.

Ich habe daher seit Montag jeden Tag etwas geübt und auch damit angefangen, das Mathe-Skript vom Professor mal ernsthaft und konzentriert durchzugehen. Das heißt, dass ich v.a. versuche, die vielen Beweise zu verstehen, um die ich bisher häufig einfach einen Bogen gemacht habe. Diese Beweise sind allerdings bis auf ganz wenige Ausnahmen absolut unverständlich… es werden z.B. ständig die unmöglichsten Umformungen gemacht ohne, dass das auch nur in einer Randnotiz vermerkt wäre – zum Kotzen!

Nach einem vollen Semester Mathematik – in dem ich mir wirklich Mühe gegeben habe, zu verstehen, was der Professor da immer predigt – und nach mehrfachen Versuchen, den Mathematikern doch noch eine Chance zu geben, lautet mein Fazit ein für allemal:

• Mathematiker erklären ihr Fach absichtlich schlecht, obwohl sie selbst bspw. von Beweisen fordern, dass sie bloß gut kommentiert und nachvollziehbar sein sollen
• Mathematiker stehlen dadurch Lebenszeit, die man auch besser nutzen könnte (um mal auf den Titel zurückzukommen)

Ich bin ja sowas von angepisst von dieser abartigen Arroganz, die die Mathematiker bei uns an der Uni an den Tag legen… das ist ja sowas von erbärmlich. Es gibt nichts, was der dümmste Dorftrottel nicht besser erklären könnte als ein Mathematiker – ich kann mir jedenfalls nichts vorstellen.
So oft haben meine Kommilitonen und ich schon gestöhnt “oh man, das ist doch eigentlich total einfach”, nachdem wir endlich etwas verstanden hatten, was uns die lieben Mathematiker auf die gottverdammt dämlichste Art und Weise versuchten, beizubringen (dieses Gefühl wird wohl jeder kennen).

Warum tun sich Mathematiker so schwer damit, ihr Fach menschlich zu erklären? Der Formalismus beißt sich nämlich kein bisschen mit Verständlichkeit (das Gegenteil wird immer von Mathematikern behauptet)!
Ich schätze, dass die Mathematiker einfach nicht wollen, dass man ihr Fach so darstellt, wie es nunmal ist: relativ simpel, wenn man’s vernünftig erklärt. Oder es ist einfach eine sehr alte Tradition und jeder Professor sagt sich “warum sollen es die Studenten von heute besser haben als ich – die sollen auch schuften müssen, auf die vernünftigen Erklärungen scheiße ich”…

Zum Schluss möchte ich noch eines sagen: Mathe ist nur eine von 4 Lehrveranstaltungen in diesem Semester. Jede Lehrveranstaltung hat es gewaltig in sich – und man ist gelegentlich immer mal frustriert. Das ist normal, wenn man studiert – erst Recht bei Informatik (es ist einfach schwer). Aber nirgends ist es a) so heftig wie bei Mathematik und b) nirgends habe ich auch nur den geringsten Anlass dazu zu denken, dass die Professoren/Tutoren ihr Fach mit Absicht schwer erklären. Im Gegenteil: Überall versucht man den Stoff so verständlich und anschaulich rüberzubringen wie nur irgendwie möglich! Nur bei Mathe nicht. Da ist es gerade andersrum… und DAS ist es, was mich so sauer macht.
Außerdem ist es so, dass Mathematik nicht nur bei uns so verhasst ist. Von verschiedenen Leuten aus meinem Abi-Jahrgang und von Studenten aus anderen Fachbereichen höre ich (im Wesentlichen) genau dasselbe.

Letztenendes muss ich da so oder so durch – und ich werde es schaffen! Und von Zeit zu Zeit werde ich den Mathematikern gehörig in den Arsch treten, indem ich ihnen zeige, wie man es besser macht…

Wichtigster Unterschied zur Schule ist, dass an der Universität keine Allgemeinbildung gelehrt wird. Man kann stattdessen einen von vielen vielen vielen Studiengängen wählen. An manchen Universitäten werden mehr Studiengänge angeboten, an anderen weniger. Ich studiere momentan B.Sc. Informatik an der TU Darmstadt. B.Sc. bedeutet Bachelor of Science und ist ungefähr gleichwertig mit einem Vordiplom. Wenn man diesen Abschluss erreicht hat, dann bedeutet dies, dass man das Grundstudium abgeschlossen hat und das Hauptstudium, in welchem man sich i.d.R. weiter spezialisiert, antreten kann.

Jeder Studiengang besteht aus einer bestimmten Anzahl von Semestern – B.Sc. Informatik hat 6 Semester. Jedes Semester ist ein halbes Jahr lang – man unterscheidet zwischen Wintersemester (1. Oktober bis 31. März) und Sommersemester (1. April bis 30. September).

Jedes Semester wiederum besteht aus bestimmten Lehrveranstaltungen. Eine Lehrveranstaltung heißt zum Beispiel “Mathematik I für Inf und WInf” (Inf=Informatiker, WInf = Wirtschaftsinformatiker) und besteht mindestens aus den zugehörigen Vorlesungen, Übungen und Prüfungen. Jede Lehrveranstaltung wird außerdem von einem Professor, dem verschiedene Hilfskräfte zur Seite stehen, geleitet.

In den Vorlesungen, die in sehr großen Hörsälen von dem jeweiligen Professor gehalten werden, wird der Stoff in sehr schnellem Tempo abgehandelt. Meistens muss man daher nach der Vorlesung einiges nacharbeiten, um den Stoff auch wirklich zu verinnerlichen. Die Vorlesungen dauern jeweils 2 Semesterwochenstunden (SWS), von denen jede 45 Minuten lang ist. Generell wird an der Universität vieles in Semesterwochenstunden gemessen. Werden für eine Vorlesung zum Beispiel 4 SWS angeben, so heißt das, dass man in dem Semester jede Woche durchschnittlich (!) 4×45 Minuten Vorlesung hat.
(Die Teilnahme an den Vorlesungen ist nicht verpflichtend, aber ratsam.)

Beim Lernen des Stoffes helfen die Übungen, die von den Veranstaltern angeboten werden. Eine Übung findet meistens einmal pro Woche oder alle 2 Wochen statt und dauert i.d.R. 2×45 Minuten. Da man nicht alle Hörer der Vorlesung in einer einzigen Übung betreuen kann, werden die Studenten verschiedenen Übungsgruppen zugeteilt. Jede Übungsgruppe besteht i.d.R. aus etwa 20-40 Studenten (das ist bei mir so) und wird von einem Tutor geleitet. Die Aufgabe des Tutors ist es, den Studenten zu helfen und ihre Fragen so gut es geht zu beantworten.
Man trifft sich dann schließlich zu bestimmten Zeiten mit seiner Übungsgruppe und dem Tutor in einer Räumlichkeit der Universität und bearbeitet verschiedene Gruppenaufgaben zum Vorlesungsstoff, die jeweils vor der Übung veröffentlicht und von den Studenten ausgedruckt und mitgebracht werden sollen. Bei der Bearbeitung der Aufgaben soll das Gelernte eingeübt werden.
(Die Teilnahme an den Übungen ist aber meistens nicht verpflichtend, aber wie bei den Vorlesungen ratsam.)

Es gibt allerdings nicht nur Gruppenaufgaben, sondern auch Hausaufgaben. Sie werden Hausübungen genannt. Diese Hausübungen sollen am besten alleine bearbeitet werden, damit man sich auch wirklich sicher sein kann, dass man die Aufgaben selbstständig lösen kann. Meistens ist es erlaubt, die Hausübungen auch in (kleinen!) Gruppen zu lösen – dies muss aber explizit angegeben werden und es muss trotzdem jeder Student seine eigene Lösung abgeben.

Die Hausübungen kann man am jeweils nächsten Übungstermin bei seinem Tutor abgeben (Anmerkung: bei manchen Lehrveranstaltungen kann man die Hausübungen auch online abgeben, natürlich besonders häufig in der Informatik und ähnlichen Fächern). Der Tutor wird die Lösungen dann bis zum nächsten Übungstermin korrigieren, ggf. sogar mit Anmerkungen versehen (wie man die Aufgabe z.B. hätte besser lösen können o.ä.).
Wichtig: Bei vielen Lehrveranstaltungen steht es dem Studenten frei, ob er seine Hausübung bearbeitet und abgibt (auch, wenn er es im eigenen Interesse tun sollte).
Bei manchen Lehrveranstaltungen werden die Hausübungen allerdings bewertet. Man nennt dies dann bewertete Hausübungen. Der Veranstalter kann dann zum Beispiel vorschreiben, dass man mindestens 50% der Punkte in den (bewerteten) Hausübungen erreichen muss, um für die Prüfung zugelassen zu werden. Die Bewertung wird von dem jeweiligen Tutor vorgenommen. Die Abgabe der Hausübungen ist bei solchen Lehrveranstaltungen natürlich Pflicht – ansonsten erhält man keine Punkte.

Zusätzlich zu den Vorlesungen und den Übungen gibt es bei manchen Lehrveranstaltungen auch noch Praktika, Seminare und weitere.
Praktika sind zum Beispiel bei “Grundlagen der Informatik I” kleine Softwareprojekte, die ebenfalls benotet werden. Dabei kommt es vor allem darauf an, das Gelernte anzuwenden. Auch die Planung usw. fließen in die Bewertung ein.
Seminare sind, soweit ich das bisher überblicken kann, benotete Vorträge, für die sich Studenten selbstständig etwas tiefer in eine bestimmte Thematik einarbeiten mussten. sind Lehrveranstaltungen kleineren Umfangs (meist über einige Wochen), an deren Ende das Gelernte entweder mit einer Hausarbeit oder einem Vortrag überprüft wird, woraus dann eine Note hervorgeht.

In den Prüfungen (der üblichen Lehrveranstaltungen) stellt sich schließlich heraus, ob die Studenten das nötige Wissen verinnerlicht haben und unter Zeitdruck anwenden können. Manche Prüfungen sind übrigens geteilt in zwei einzelne Klausuren (die dann für das Gesamtergebnis zusammengerechnet werden). Die Prüfungen finden während der Semesterferien statt. Es handelt sich also gar nicht um echte Ferien – es werden lediglich keine Vorlesungen mehr gehalten, daher auch vorlesungsfreie Zeit genannt.
Zu den Prüfungen ist anzumerken, dass die Veranstalter teilweise komplizierte eigene Regelungen vorsehen. So ist es beispielsweise bei manchen Lehrveranstaltungen so, dass überschüssige Punkte aus den bewerteten Hausübungen zur Verbesserung der Prüfungsnote genutzt werden können. Wenn man sich in den entsprechenden Hausübungen gut schlägt, kann man seine Prüfungsnote am Ende also nochmal deutlich verbessern!
Weiterhin ist zu sagen, dass man die Prüfungen in der Regel relativ leicht schaffen sollte, wenn man die Vorlesungen und Übungen regelmäßig besucht und seine Hausübungen macht. Der Stoff ist schwer, aber man bekommt viel Unterstützung bis zur Prüfung.

Wenn man eine Prüfung nicht besteht, muss man sie – wenn möglich – in einem späteren Semester wiederholen oder das Studium abbrechen. Meistens hat man eine begrenzte Anzahl von Versuchen.

Das waren so die wichtigsten Elemente des reinen Studentenlebens.
Während der Vorlesungszeit geht man in die Vorlesungen, besucht die Übungen, macht seine Hausübungen usw. Wie viel Zeit das etwa kostet, kann ich noch nicht genau beschreiben, weil es im 1. Semester natürlich etwas langsamer los geht. Für die zweite Hausübung von Grundlagen der Informatik I habe ich aber immerhin fast 4 Stunden gebraucht. (Ich werde in einigen Wochen, wenn es richtig hart wird, an dieser Stelle einen kleinen Aufwandsvergleich zur Oberstufe einfügen.)
Wenn die Vorlesungen dann vorbei sind, bereitet man sich auf die Klausuren vor. Das schwierigste dabei ist, dass es die meiste Zeit über niemanden gibt, der einen dazu zwingt, zu lernen. Es gibt Menschen, die damit besser umgehen können und es gibt Menschen, die damit eher nicht zurecht kommen – und der Stoff ist wirklich hart.

Alles in allem macht mir persönlich das Studium bisher wirklich Spaß! Das liegt zum einen daran, dass der Stoff wirklich anspruchsvoll ist und man definitiv nicht gelangweilt ist. Zum anderen ist es schlicht und ergreifend so, dass der Anteil dessen, was mich absolut nicht interessiert, sehr gering ist. Diese ganzen Schulfächer, die man ohne Weiteres aus dem Lehrplan streichen könnte, gibt es jetzt nicht mehr.

Als letzter Hinweis sei noch gesagt, dass für Erstsemester (Ersties) von der Universität oder von höhersemestrigen Studenten sogenannte Orientierungsphasen bzw. Einführungswochen angeboten werden. Alles, was in diesem Artikel beschrieben ist und noch viel viel mehr, wird dann innerhalb von 1 Woche o.ä. ausführlich erklärt. Man wird also auf keinen Fall im Regen stehen gelassen.

Mit Hilfe des Lehrmaterials “Turtle-Grafik und Fraktale Geometrie” (http://miami.uni-muenster.de/servlets/DocumentServlet?id=1522) konnte ich auch recht schnell einsteigen. Die Schilderungen und die Quelltexte sind auf das Modul turtle bezogen und sind somit grundsätzlich plattformunabhängig. Dennoch empfehle ich Python für diese Experimente, denn dort ist das turtle-Modul bereits integriert und lässt sich phänomenal einfach verwenden.

Das turtle-Modul

Das turtle-Modul ist eine Sammlung an Funktionen, mit deren Hilfe sich ein “Malstift” bzw. “turtle” steuern lässt. Mit Anweisungen wie left(), right(), forward() und backward() kann man einfachste Bewegungen koordinieren. Packt man derartige Anweisungen in rekursive Funktionen, so ergibt sich mit etwas Glück ein immerwiederkehrendes selbstähnliches Gebilde – ein Fraktal.

Die Dokumentation des pythoneigenen turtle-Moduls ist hier zu finden:

http://docs.python.org/lib/module-turtle.html

Die Kochkurve

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

# coding=UTF-8
from turtle import *
import time
 
 
def kochkurve(t, s):
    if(t==0):
        # wenn die gewünschte rekursionstiefe (sprich: feinheit der bewegungen) erreich ist,
        # soll das ganze auf dem bildschirm umgesetzt werden
        forward(s)
    else:
        # die bewegungen der "turtle" werden rekursiv verfeinert
        kochkurve(t-1, s/3)
        left(60)
        kochkurve(t-1, s/3)
        left(-120)
        kochkurve(t-1, s/3)
        left(60)
        kochkurve(t-1, s/3)
 
 
# koch'sche schneeflocke, zusammengesetzt aus mehreren kochkurven
kochkurve(3, 100)
left(-90)
color(1,0,0)
kochkurve(3, 100)
left(-90)
color(0,1,0)
kochkurve(3, 100)
left(-90)
color(0,0,1)
kochkurve(3, 100)
 
# die methode done(), die die hauptschleife betritt, ist offenbar nicht verfügbar :-(
time.sleep(10)
done()

Die Rekursionstiefe (t) bestimmt die Feinheit der Bewegungen. Der Parameter s definiert die Gesamtlänge der Kochkurve.

Ich habe die Funktion am Ende mehrfach aufgerufen, sodass eine sogenannte Koch’sche Schneeflocke entsteht. Eine Koch’sche Schneeflockte besteht aus mehreren Kochkurven, die man aneinandergehängt hat. Und hängt man 4 Kochkurven im Winkel von 90° aneinander, so ergibt sich folgendes Gebilde:

Der fraktale Baum

Fraktale Bäume haben mich irgendwie schon immer beschäftigt. Man stelle sich einen Körper vor, von dem etliche Zweige und Äste abgehen. Von jedem Zweig und jedem Ast gehen erneut ebensoviele Zweige und Äste ab – diesmal nur wesentlich kleiner. Und von diesen kleinen Ästen gehen wieder Äste ab … immer wieder … und jedes Mal werden sie kleiner. Ich hatte meinen Spaß daran mir den kleinsten denkbaren Ast vorzustellen. Natürlich hatte dieser Gedankengang nie ein Ende. Aber wenn man jung ist…

Mit dem turtle-Modul lassen sich natürlich auch fraktale Bäume erzeugen.

Z.Bsp. hiermit:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

# coding=UTF-8
from turtle import *
import time
 
 
def baum(s,t):
    if(t >= 0):
        forward(s)
        left(30)
        baum(s*0.6, t-1)
        right(75)
        baum(s*0.7, t-1)
        left(45)
        backward(s)
 
 
sety(-100)
baum(100,7)
 
# die methode done(), die die hauptschleife betritt, ist offenbar nicht verfügbar :-(
time.sleep(10)
done()

Mit Hilfe des Parameters t lässt sich auch hier die Rekursionstiefe festlegen.

Der Code ergibt, wenn man ihn mit dem Python-Compiler aufruft, folgendes:

Selbstverständlich lassen sich Winkel und Streckenlängen variieren. In diesem konkreten Fall ist der linke Ast um 30° (nach links), der rechte um 45° (nach rechts) abgewinkelt. Der linke Ast hat die Länge 0,6*s – das entspricht 60% der Länge des Mutterastes. Der rechte Ast hat jeweils die Länge 0,7*s – also 70% der Länge des Mutterastes.

Weitere Anregungen

Fischpopulationen im Lehrerzimmer mit Tkinter (kleine Andeutung am Rande )

Turtle-Grafik und fraktale Geometrie