1. Vorlesung: Einführungen zu Compilern, grober Aufbau.
2. Vorlesung: Wir beschäftigen uns nun mit der Syntaxanalyse, die in den Compilern durchgeführt wird. Dazu gucken wir uns nochmals kontextfreie Grammatiken an.
3. Vorlesung: Es ging um syntaxgerichtete Übersetzung und Syntaxschemata.
4. Vorlesung: Es ging um die Syntaxanalyse des Parsers und wie man prädiktive Syntaxanalyse betreiben kann
5. Vorlesung: Wir haben die bisher besprochenen Komponenten zu einem vollständigen Front-End eines Übersetzers kombiniert.
6. Vorlesung: Die lexikalische Analyse war heute Thema.
7. Vorlesung: Wir haben uns die Interaktion zwischen Lexer und Parser angeschaut und wie man Fehlerbehandlung schon im Lexer betreiben kann.
8. Vorlesung: Wir haben uns mit regulären Definitionen beschäftigt.
9. Vorlesung: Wir haben uns überlegt, wie man Token durch endliche Automaten erkennen kann.
10. Vorlesung: Der Lexer-Generator Lex wurde vorgestellt.
11. Vorlesung: Syntaxanalyse im Parser (höchst unvollständig ;-))
12. Vorlesung:  Wir haben uns Techniken angesehen, wie man Nichtterminismus Eliminieren kann. Ein Beispiel ist die Eliminierung der Linksrekursion oder die Linksfaktorisierung.
13. Vorlesung: Wir haben die deterministische Top-Down-Syntaxanalyse betrachtet und wie man FIRST- und FOLLOW-Mengen bildet.
14. Vorlesung: Als Fortsetzung der Top-Down-Analyse haben wir eine Parse-Tabelle aufgestellt und geguckt, wie man damit eine Fehlerbehandlung betreiben kann.
15. Vorlesung: Es ging weiter mit der Parse-Tabelle. Dann haben wir noch mit der Bottom-Up-Analyse angefangen.
16. Vorlesung: Weiter mit Bottom-Up-Analyse. Und wir haben uns die Shift-Reduce-Analyse angeschaut.
17. Vorlesung: Die einfache LR-Syntaxanalyse (Simple LR-Parser) war Thema.
18. Vorlesung: Struktur und Aufbau der Parse-Tabelle bei SLR
19. Vorlesung: Semantische Analyse und syntaxgerichtete Definitionen war Thema.
20. Vorlesung: Wir haben uns die topologische Sortierung von SDDs angeschaut.
21. Vorlesung: Wir haben uns als weitere Anwenund syntaxgerichteter Definitionen Syntaxbäume angeschaut.
22. Vorlesung: Statt einem Syntaxbaum erstellen wir nun einen DAG (directed acyclic graph)
23. Vorlesung: Wir beginnen mit dem Abschnitt Zwischencode-Erzeugung. Als einen Vertreter davon betrachten wir den 3-Adress-Code
24. Vorlesung: Wir schauen uns an, wie man 3-Adress-Code für imperative Programmiersprachen erzeugen kann.
25. Vorlesung: Laufzeitumgebungen sind das Thema.
26. Vorlesung: Codeerzeugung und Kosten von Befehlen
27. Vorlesung: Grundblöcke und Flussgraphen
28. Vorlesung: Lebendigkeit und nächste Verwendung mit dem Blick auf Code-Optimierung

Download der Übersetzerbau Mitschrift

1. Vorlesung: Ausblick in Mustererkennung anhand von Viola-Jones (siehe Paper)
2. Vorlesung: KNN (k nearest neighbours) Algorithmus
3. Vorlesung Clustering (k-means) und unüberwachtes Lernen
4. Vorlesung: EM-Algorithmus (Expectation Maximization) und Lineare Regression
5. Vorlesung: PCA (Principal Component Analysis) und der Algorithmus von Oja
6. Vorlesung: Fisher’s linear discriminant
7. Vorlesung: Perzeptrons und Perzeptronlernen (Dank an Lisa für ihre Mitschrift!)
8. Vorlesung: Verallgemeinerung des Perzeptron-Lernalgorithmus (Neuronale Netze) mit Backpropagation
9. Vorlesung: Backprop-Algorithmus mit Matrizen und Verfeinerungen mit Silva & Almeida, Momentum und RPROP.
10. Vorlesung: Blind source separation (independent component analysis)
11. Vorlesung: Non-negative matrix factorization
12. Vorlesung: Entscheidungsbäume und ID3-Algorithmus
13. Vorlesung: Über Merkmalsextraktionen und bekannte Features
14. Vorlesung: Boosting

Download der Mustererkennungsmitschrift (27 MB da Scan!)

• Stoffzusammenfassung für die Datenbanksystem-Prüfung in anwendungsorientierter Informatik
• Zusammenfassung für die Telematik-Prüfung in technischer Informatik

Für die weiteren Prüfungen (Höhere Algorithmik etc.) plane ich auch solche Zusammenfassungen und werde die Materialienliste also nach und nach erweitern.

1. Vorlesung: Farbsegmentierung
2. Vorlesung: Farbtabellen mit KD-Bäumen
3. Vorlesung: Radiale Verzerrung bzw. Entzerrung
4. Vorlesung: Lokalisierung im Raum anhand 3 bzw. 4 Punkten
5. Vorlesung: Fortsetzung zu Lokalisierung, diesmal mit EM-Algorithmus. Quaternionen angeschnitten.
6. Vorlesung: Fortsetzung zu Quaternionen, Rotation und homogene Koordinaten dazu.
7. Vorlesung: Stereo Vision und Tiefeninformation
8. Vorlesung: Optischer Fluss (Optical Flow)
9. Vorlesung: SIFT Features (nicht im Skirpt enthalten, da Slides)
10. Vorlesung: Hough-Transformation und Harris-Corner-Detector

Download Computer Vision Mitschrift (ca. 14MB, da Scan!)

Zwischenergebnis Gallerie

Einheitliches Layout

Im Verlauf des Tutorials werden mehrere Seiten erstellt. Schön wäre es da, wenn man ein einheitliches Layout einfach produzieren könnte, so dass z.B. auch überall die selbe Navigation erscheint oder die selben CSS-Dateien eingebunden werden. In Wicket läuft dieser Prozess unter dem Namen “Markup Inheritance”.

Bei Wicket ist es so, dass zu jeder sichtbaren Seite eine Java-Klasse und eine HTML-Datei gleichen namens existieren müssen, die auch im selben Verzeichnis liegen, bei mir im Package page. Zudem muss die Klasse von WebPage erben, das ist die Standardklasse für Webseiten von Wicket.

Wir erstellen uns also zunächst eine abstrakte Layout-Klasse, die die Funktionalität zu Verfügung stellt, welche alle anderen Klassen von ihr erben sollen. Zunächst wollen wir nur, dass jede Seite einen Titel bekommt und in der Fusszeile das aktuelle Datum erscheint.

public abstract class Layout extends WebPage {
	private String title = "Layout title";
	private Date date;
	public Layout() {
		date = new Date();
		add(new Label("title", new PropertyModel(this, "title")));
		add(new Label("pageTitle", new PropertyModel(this, "title")));
		add(new Label("date", new PropertyModel(this, "date")));
	}

	public void setTitle(String t) {
		title = t;
	}

	public String getTitle() {
		return title;
	}

Ein Label ist in Wicket einfach ein ganz normales Textobjekt, welches durch add() als sichtbar markiert wird und dann auch ein Äquivalent im HTML-Code besitzen muss. Generell benötigt jede Komponente, die man zu einer Seite hinzufügt, mindestens zwei Angaben. Erstens den Namen, über den das Objekt im HTML-Code referenziert wird (hier z.B. “title” oder “date”) und ein Model, von welchem der Inhalt der Komponente stammt. Über die Angabe von new PropertyModel(this, "title") wird ein PropertyModel erstellt, welches in dem aktuellen Objekt (this) eine Objektvariable mit dem Namen “title” sucht uns dieses dort einbindet. Genauso geht das mit dem Datum.

Ich habe gesagt, dass zu jeder Klasse, die von WebPage erbt, eine gleich benannte HTML-Datei existieren muss. Diese gucken wir uns nun an und schauen, wie wir ganz simpel Objekte, die per oben beschriebener add() Methode hinzugefügt wurden, im HTML-Quellcode referenzieren und einbinden können.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title wicket:id="pageTitle">Insert title here</title>
</head>
<body>
<div id="header"><h1 wicket:id="title">title here</h1></div>

<!-- Begin main -->
<div id="main">
	<wicket:child />
</div>
<!-- End main -->

<div id="footer"><small wicket:id="date">date</small></div>
</body>
</html>

Es ist zu erkennen, dass es sich bei der Layout.html um eine ganz normale HTML-Datei handelt. Das einzige bisschen mehr, was wir noch kennen müssen, um Wicket an entsprechender Stelle Inhalte einfügen zu lassen, ist der Zusatz wicket:id="{hier die entsprechende Bezeichnung}", die als Zusatz in jeden x-beliebigen HTML-Tag eingebaut werden kann. Es funktioniert so, dass man z.B. wie unten im Footer in den Small-Tag das aktuelle Datum rein generieren lassen möchte. So fügt man also wicket:id="date" hinzu. Dann wird automatisch beim Aufruf der Wert der add() Methode mit dem Bezeichner “date” hier eingebunden. Das date, was im HTML-Code schon zwischen dem Anfang- und Ende-Tag steht, dient nur als Platzhalter und zur besseren Übersicht, er kann auch weggelassen werden.

So simpel ist das! Interessant zu erwähnen ist noch der neue Wicket-Tag <wicket:child /> mit dem dann an entsprechender Stelle generierter Code aus einer anderen Wicket-Klasse eingefügt wird. Wie es genau funktioniert, wird später deutlich.

1. Vorlesung: Einführung in Algorithmen und Effizienz anhand von ein paar Sortieralgorithmen.
2. Vorlesung: Fortsetzung von der vorhergehenden Stunde.
3. Vorlesung: Wir haben mit Berechnungsmodellen angefangen, im speziellen mit Turinmaschinen und RAMs.
4. Vorlesung: Weiter im Text mit Berechnungsmodellen und wie man sie vergleichen kann. Und noch ein paar Bemerkungen zum Suchen und Sortieren
5. Vorlesung: Nachdem wir uns zu Ende über das Suchen und Sortieren Gedanken gemacht haben, haben wir mit dem Auswahlproblem angefangen.
6. Vorlesung: Wir haben uns ein deterministisches Auswahlverfahren angeguckt und dann mit Binärsuche und als Verbesserung dazu die Interpolationssuche angeschaut.
7. Vorlesung: Wir haben die Suchverfahren mit der Quadratischen Binärsuche abgeschlossen.
8. Vorlesung: Das neue Kaptiel heißt Datenstrukturen. Wir widmen uns dem Wörterbuchproblem und gucken uns sortierte Arrays, Hashing, binäre Suchbäume, AVL-Bäume und BB[α]-Böume an.
9. Vorlesung: Weiter mit dem Wörterbuchproblem und (a,b)-Bäumen, Rot-Schwarz-Bäumen und schlussendlich Tries. Optimale binäre Suchbäume wurden angerissen, damit geht es nächstes mal weiter.
10. Vorlesung: Es ging weiter mit den optimalen Suchbäumen. Wir haben zum Aufbau von solchen Bäumen einen Algorithmus kennengelernt.
11. Vorlesung: Abschließend zu optimalen Suchbäumen haben wir den Algorithmus analysiert und gesehen, wie man ihn optimieren kann. Dann haben wir mit dem Vereinige-Finde-Problem (oder auch Union-Find) angefangen.
12. Vorlesung: Wir haben Union-Find analysiert und per Pfadkompression weiter verbessert.
13. Vorlesung. Es wurde mit Graphen angefangen. Nach vielen Definitionen ging es auch kurz um Travsersierungen und topologisches Sortieren. Danke an Gero, der mir seine Tafelbilder zu Verfügung gestellt hat.
14. Vorlesung: Wir haben angeguckt, wie man mit dem Algorithmus von Kruskal minimal spannende Bäume baut und wie Dijkstra kürzeste Wege findet.
15. Vorlesung: Wir haben uns mit dem Floyd-Warshall-Algorithmus beschäftigt, der das All-Pairs-Shortest-Path-Problem löst.
16. Vorlesung: Nach den Wegproblemen folgen nun die Flüsse in Netzen. Wir haben den Ford-Fulkerson-Algorithmus kennen gelernt, der den maximalen Fluss berechnet.
17. Vorlesung: Weiter mit Ford-Fulkerson.
18. Vorlesung: Zuende mit Ford-Fulkerson und dann gleich noch Edmonds-Karp hinterher, der ein wenig anders als Ford-Fulkerson funktioniert.
19. Vorlesung: Als letztes zum Thema Graphen haben wir uns das bipartite Matching angeschaut. Das neue Kapitel ist nun String Matching.
20. Vorlesung: String Matching haben wir fortgeführt und und den Algorithmus von Knuth-Morris-Pratt weiter angeschaut. Und dann dazu auch noch Suffixbäume.
21. Vorlesung: Wir haben das Kapitel String Matching abgeschlossen und mit NP-Vollsändigkeit angefangen.
22. Vorlesung: Wir haben uns die Klassen P und NP angeschaut und definiert, was polynomzeit Reduktion ist.
23. Vorlesung: Wir haben definiert, was NP-schwer und NP vollständig bedeutet und gezeigt, dass CSAT (Schaltkreiserfüllbarkeit) ein NP vollständiges Problem ist.
24. Vorlesung: Wir haben uns weitere NP vollständige Probleme angeschaut. Es kam SAT …
25. Vorlesung: … 3-SAT, CLIQUE …
26. Vorlesung: … UK (Unabhängige Knotenmenge), ÜK  (überdeckende Knotenmenge), SUBSET-SUM und GHK (gerichteter Hamiltonscher Kreis).
27. Vorlesung:  Wir haben uns andere Komplexitätsklassen angeschaut. Darunter waren Co-NP, PSPACE und EXPTIME.
28. Vorlesung: Approximationsalgorithmen heißt das neue Kapitel. wir widmen uns zunächst Delta-TSP mit der Baumheuristik.
29. Vorlesung: Wir lernen die Christofides-Heuristik für Delta-TSP kennen und zeigen, warum das normale TSP nicht approximierbar ist.
30. Vorlesung: Wir lernen einen PTAS (polynomial time approx scheme) für SUBSET-SUM kennen.

Anmerkung: Die letzten drei Vorlesungen sind noch nicht überarbeitet! Aber da sicherlich einige schon jetzt reinschauen wollen um für die Klausur zu lernen, stelle ich es schon online. Ich versuche aber noch vor Freitag meine Notizen durchzugehen und zu überarbeiten. Ich wünsche schonmal allen viel Erfolg beim Lernen und vor allem bei der Klausur!

Edit (12.02.09, 15.00): Nun sind auch die letzten drei Vorlesungen überarbeitet!

Download Höhere Algorithmik Mitschrift

An Wicket mag ich besonders, dass wie bei Click HTML-Code und Java-Quellcode komplett getrennt sind, und es nur eine Handvoll HTML-Befehle gibt, die man braucht um Wicket-Klassen anzusprechen. Im Gegensatz zu Click ist Wicket aber wesentlich besser zu konfigurieren und stellt mehr Funktionalität zu Verfügung. Genauso wie bei Click gibt es zudem Online-Beispiele, bei denen man schon mal einige simple Anwendungen direkt am Quellcode nachvollziehen kann.

Meine erste Anwendung besteht aus einer Bildergallerie, die die Bilder in einer (Postgres)-Datenbank speichert. Es gibt natürlich auch eine Upload-Funktion zum einfachen Einfügen neuer Bilder. Im Folgenden will ich also einen kurzen Überblick über die (recht simple) Gallerie bieten und daran ein wenig zeigen, wie Wicket funktioniert.

Jetzt noch kurz was zur Vorbereitung, ehe es dann richtig los geht.

Vorbereitungen

Ich benutze Eclipse 3.4 mit integrierten JEE Tools. Dort habe ich mir ein neues dynamisches Web Projekt namens “ImageGallery” angelegt mit Tomcat 5.5 als Umgebung. Im erzeugten Ordner WebContent/WEB-INF/lib fügt man dann noch neben den ganzen Wicket 1.3.4 Bibliotheken die commons-dbcp.jar und commons-pool.jar für das Connection Pooling und die Postgres-Treiber (oder Treiber für eine andere Datenbank) ein.

Image-Objekt und Datenbank

Dann kann man soweit loslegen und die Datenbank anlegen, in der die Bilder und deren Metainformationen gespeichert werden sollen. Da es sich um eine ganz einfache Anwendung handelt, wird nur eine eindeutige ID, die Bilddatei mit Mime-Typ, Größe und Namen, der Name des Uploaders und der Zeitstempel des Uploads gespeichert.

CREATE TABLE images
(
  id serial NOT NULL,
  file bytea NOT NULL,
  mime_type character varying(20) NOT NULL,
  uploader character varying(50),
  date timestamp with time zone NOT NULL,
  name character varying(50),
  size integer NOT NULL,
  CONSTRAINT images_pkey PRIMARY KEY (id)
)

Um in Java nun so ein Bild abbilden zu können, baue ich mir ein Objekt Image zusammen, welches alle Spalten der Datenbank als Felder enthält. In Wicket werden solche Klassen auch als Model bezeichnet, daher wird die Klasse auch bei mir im Java-Package model abgelegt. Zudem implementiert sie das Interface IModel, da hierdurch die Anwendung ganz einfach mit den Objekten umgehen kann.

public class Image implements IModel {
	private static final long serialVersionUID = 6292744495006923192L;
	private Image image; // das Objekt selber!
	private int id;
	private String name;
	private byte[] file;
	private long size;
	private String mime;
	private String uploader;
	private Timestamp date;

	public Object getObject() {
		return image;
	}

	public void setObject(Object image) {
		this.image = (Image) image;
	}

	public void detach() {
	}
}

Natürlich hat jede Variable noch entsprechende Getter-und Settermethoden, die aus Platzgründen einfach mal weggelassen werden. Die drei Methoden detach(), getObject() und setObject() stammen übrigens aus dem implementierten Interface. Durch diese Methoden wird es möglich ganz einfach dann die Wicket-internen Mechanismen zu benutzen, um später die Tabelle für die Gallerieansicht zu füllen.

Jetzt kümmern wir uns um die Verbindung zur Datenbank und das reibungslose Übertragen von Bildern in die Datenbank und von der Datenbank in unsere Applikation.
Als erstes muss natürlich eine Verbindung zu der Datenbank hergestellt werden, auf der dann die ganzen SQL-Befehle abgesetzt werden. Damit das ganze auch gut konfigurierbar ist und mit beliebigen Datenbanken funktioniert, verwende ich eine Properties-Datei gallery.properties, die bei mir im Package config liegt. Eine minimale Properties-Datei könnte z.B. so aussehen:

#Einstellungen für die DB
url=jdbc:postgresql://localhost:5432/imagegallery
username=postgres
password=
driverClassName=org.postgresql.Driver

Jetzt kann in der Klasse, welche die Verbindung managen wird, einfach die Properties-Datei eingelesen werden und auf den Parameter gearbeitet. Die Klasse heißt bei mir ConnectionPooling und liegt im Package service. Ich habe ganz frech einfach mal die Version übernommen, die ich mit meiner Gruppe für das Datenbankprojekt verwendet habe.

public class ConnectionPooling {
	private static ConnectionPooling cp=null;
	private DataSource dataSource;
	private Properties dbProp;
	private PoolableConnectionFactory pcf;
	private GenericObjectPool gPool;

	//der Konstruktor ist private, weil wir ein Singleton nehmen.
	private ConnectionPooling() {
		dbProp = new Properties();
		try {
			ClassLoader loader = this.getClass().getClassLoader();
			InputStream stream = loader.getResourceAsStream("config/gallery.properties");
			//Properties einlesen
			dbProp.load(stream);
			dataSource = BasicDataSourceFactory.createDataSource(dbProp);
			//Pooling machen
			gPool = new GenericObjectPool();
			pcf = new PoolableConnectionFactory(new DataSourceConnectionFactory(dataSource),gPool,null,null,false,false);
			//ein Paar Verbindungen vorbereiten
			for (int i=0 ; i < 5 ; i++) {
				   gPool.addObject();
			}
		} catch (FileNotFoundException e) {
			e.printStackTrace();
		} catch (IOException e) {
			e.printStackTrace();
		} catch (Exception e) {
			e.printStackTrace();
		}
	}

	/**
	 * Wir benutzen ein Singleton-Pattern für den ConnectionPool
	 * @return Einen ConnectionPool. Immer den selben.
	 */
	public static synchronized ConnectionPooling getInstance() {
			if (cp==null) {
				cp=new ConnectionPooling();
			}
			return cp;
	}

	/**
	 * @return Eine neue Verbindung aus dem Pool
	 */
	public Connection getConnection(){
		Connection conn = null;
		try {
			conn = (Connection) gPool.borrowObject();
		} catch (Exception e) {
			e.printStackTrace();
		}
		return conn;
	}
}

Wir haben hier ein Singleton-Pattern, damit nur eine Instanz erzeugt wird, mehr brauchen wir ja auch nicht. Da wir das Apache Commons Pooling benutzen, reicht es aus einfach nur die Properties-Datei einzulesen und dann dem DataSource-Objekt zu übergeben, das einrichten erledigt dann die BasicDataSourceFactory für uns. Mit der PoolableConnectionFactory bauen wir dann die poolbare Verbindung auf, die auf die DataSource, die durch die Properties konfiguriert ist, zugreift und im GenericObjectPool gPool die entsprechenden zu poolenden Objekte findet.
Mit dem Aufruf von ConnectionPooling.getInstance().getConnection() wird dann immer eine vorbereitete Verbindung aus dem Pool zurückgeliefert.

Den Datenzugriff erledigt dann aber die ImageDAO-Klasse (DAO für Data Access Object). Hier zeige ich nur kurz das implementierte Interface, da es sich nur um einfache INSERT und SELECT Befehle handelt und es hier einfach zu lang würde.

public interface ImageDAO {

	/**
	 * Erstellt eine Liste aller Images in der Datenbank
	 * @return Liste der Bilder.
	 */
	public List<img alt="" /> listImages();

	/**
	 * Erstellt eine Liste aller Images sortiert nach orderBy
	 * @param orderBy Befehl in SQL-Syntax, wie "id asc", "name desc" ...
	 * @return sortierte Liste
	 */
	public List<img alt="" /> listImagesOrdered(String orderBy);

	/**
	 * Fügt ein neues Bild der Datenbank hinzu
	 * @param img einzufügendes Bild.
	 * @return true, wenn alles glatt geht, false bei einem Fehler
	 */
	public boolean addImage(Image img);

	/**
	 * Holt das entsprechende Image aus der Datenbank
	 * @param id
	 * @return Image-Objekt
	 */
	public Image getImage(int id);

	/**
	 * Löscht das Bild mit der entsprechenden ID
	 * @param id
	 * @return true, falls erfolgreich, false sonst
	 */
	public boolean deleteImage(int id);

	/**
	 * Das bereits geänderte Image-Objekt soll in der Datenbank aktualisiert werden.
	 * @param img das geänderte Objekt
	 * @return true, falls erfolgreich, false sonst
	 */
	public boolean editImage(Image img);
}

So, dass war’s fürs erste. Wir können nun schon die Datenbankverbindung herstellen und theoretisch mittels der ImageDAO auch einfügen, sortieren, editieren. Wie dann die Wicket-Applikation aufgebaut wird, sehen wir im nächsten Teil, der hoffentlich schnell folgt.

Das bisherige Eclipse-Projekt mit allen Klassen und Bibliotheken kann hier heruntergeladen werden.

Forsetzung:
Bildergallerie mit Apache Wicket, Teil 2

Aus dem WS 09/10

• Übersetzerbau (Mitschrift / Übungen)
• Theoretische Physik für Lehramtskandidaten I (Übungen)

Aus dem SoSe 09

• Computer Vision (Mitschrift / Übungen)
• Mobile Communications
• Künstliche Intelligenz (Übungen)

Aus dem WS 08/09

• ALP V (Übungen)
• Telematik
• Höhere Algorithmik (Mitschrift / Übungen)
• Mustererkennung (Mitschrift / Übungen)

Aus dem SoSe 08

• ALP IV (Übungen)
• TI IV (Protokolle)
• Datenbanksysteme (Übungen)
• Softwaretechnik (Übungen)
• Physik-Praktikum

Aus dem WS 07/08

• MAFI III (Mitschrift / Übungen)
• ALP III (Mitschrift / Übungen)
• TI III (Übungen)
• Physik für Nebenfächler (Mitschrift / Übungen)

Aus dem SoSe 07

• MAFI II (Mitschrift / Übungen)
• ALP II (Mitschrift / Übungen)
• TI II (Übungen)
• GTI (Mitschrift / Übungen)

Aus dem WS 06/07

• MAFI I (Mitschrift (unvollständig) / Übungen)
• ALP I (Mitschrift (unvollständig) / Übungen)
• TI I (Übungen)

Zusätzlich sollte das Spiel eine Netzwerkschnittstelle enthalten, mit der es möglich sein sollte, sich zu anderen Reversi-Spielen zu verbinden bzw. selber einen Spielserver zu Verfügung zu stellen. Dazu wurde uns ein Netzwerkprotokoll an die Hand gegeben, welches wir umsetzten mussten. Dies war übrigens auch mit mein Part, zusätzlich durfte ich noch (mehr schlecht als recht ;-) ) das Projekt managen.

Natürlich sollte man nicht nur Mensch gegen Mensch spielen können, sondern auch gegen einen Computergegner antreten, weswegen ein solcher natürlich auch integriert werden musste. Das war auch der komplexeste Aufgabenbereich des Projekts und bietet bei meiner Gruppe noch viele Verbesserungsmöglichkeiten.

Meine Gruppe (7) hat zum Schluss auch eine gut spielbare Version abgeliefert. Das Projekt und unser Ergebnis ist übrigens unter SplineForge als Projekt “Reversi” gehostet. (Update: SplineForge war gestern. Heute heißt es dev.spline.de und dahin wurde das Projekt allerdings nicht migriert.) Wer Interesse hat kann sich an mich wenden – für Fragen bin ich auch offen …

Ich muss sagen, mir hat das sehr viel Spaß gemacht, war zwar extrem viel Arbeit, aber ein größeres Projekt umzusetzen, bei dem man ein Ziel vor Augen hat, ist doch wesentlich motivierender als die sonstigen Programmieraufgaben, die es in ALP 1-3 zu erledigen galt.

Aber kein Gewähr, dass meine richtig sind, sie sind so wie abgegeben ;-) Hab aber insgesamt gut 80-90% der Punkte, da wird also der Großteil stimmig sein …

MAFI III-Lösungen (Zettel 1-13, ohne 9)
ALP III-Lösungen (Zettel 1-12)

Ach, ist jemand eigentlich auch an Physik Ergebnissen interessiert? Die Klausur ist jetzt zwar vorbei, aber trotzdem. Fragen kostet ja nüschts …

(warum informiert mich niemand, dass ich Übungszellel geschrieben habe?)