Vorbereitung

Zuerst einmal muss man das Problem in einer für Open Office Calc lesbaren Variante in eine Tabelle eingeben. Als Beispiel nehme ich dieses (sinnlose, beispielhafte) LP:

max  5a +7b -6c +2d
s.t.  6a +8b <= 7
     -4c +9d <= 20
     a,b,c,d >= 0

Als Spreadsheet sieht das Ganze bei mir dann so aus:

In der oberen Tabelle gibt man die Zielfunktion an. Dazu legt man zuerst einmal für jede Variable eine Zelle an (im Bild blau markiert). Jetzt braucht man eine Zelle, in der die Zielfunktion berechnet wird (im Bild rot umrahmt). Diese Berechnung muss natürlich mit Referenzen auf die Zellen erfolgen. Ich habe der Einfachheit halber noch die Koeffizienten aus der Zielfunktion in extra Zellen notiert (grüner Rahmen), so dass ich in der Zielfunktionszelle einfach aufsummieren kann. In der ersten Zelle im grünen Rahmen steht bspw.:

=B2*5

Und in der roten Zelle steht entsprechend nur:

=SUMME(C2:C5)

Wenn man lieber die Zielfunktion direkt eintragen will, würde das in unserem Beispielfall so aussehen:

=5*B2+7*B2-6*B4+2+B5

Der nächste Schritt ist nun die Eingabe der Nebenbedingungen. Es gibt dafür unterschiedliche Möglichkeiten, aber ich habe es jetzt mal übertrieben exakt notiert, damit es übersichtlich bleibt. Die Zellen in der gelb umrahmten Box enthalten die Bedingungen aus dem LP als Gleichung mit Referenzen auf die Zellen in der blauen Box. Die letzte Zeile enthält die erste Nebenbedingung und sieht so aus:

=(-4)*B4+9*B5

Der Teil rechts davon ist nicht so wichtig. Man kann das so machen, aber genauso gut kann man es sich auch schenken.

Der Solver

Nun ruft man über das Menü “Extras” den “Solver” auf. Es öffnet sich ein Dialog, den man wie folgt ausfüllen muss:

Als Ziel gibt man die Zelle mit dem Wert der Zielfunktion an (im Bild oben mit rotem Rahmen). In dem etwas seltsam betitelten Feld “Durch Zellenänderung” soll man die Zellen angeben, in denen die Variablen stehen. Man markiert also den Bereich, der im Bild oben blau umrahmt ist.

Etwas aufwändiger ist es nun, die Nebenbedingungen einzugeben, da man sie alle einzeln angeben muss. Man wählt “hinzufügen” und in dem kleinen Dialog kann man dann die Zelle auswählen, in der der Wert der Nebenbedingung berechnet wird. Dann kann man eine Relation auswählen und einen Wert eingeben (oder wie hier im Beispiel referenzieren).

Wenn es nötig ist, kann man jetzt unter “Optionen” noch einstellen, dass nur positive oder nur ganze Zahlen als Variablenbelegungen erlaubt sind.

Hinweis: Im neuen Open Office 3.0 sieht der Solver etwas anders aus. Funktionieren sollte er aber genauso.

Die Lösung

Ist alles fertig eingegeben, drückt man auf “Lösen” und bekommt (hoffentlich) eine Bestätigung, dass eine Lösung gefunden wurde. In meinem Fall sah das Spreadsheet dann so aus:

Open Office hat nun die Variablen so belegt, dass der Zielfunktions-Wert maximiert wird.

Wenn du dir nochmal mein Beispiel genauer anschauen willst, kannst du dir hier auch das Spreadsheet runterladen. Wenn du den Solver öffnest, ist es möglich durch einen Klick auf “Laden” meine Einstellungen aufzurufen.

• Solver Tutorial Spreadsheet

Sonderzeichen

In der mathematischen Notation der Logik werden Sonderzeichen gebraucht, bspw. um Auswertungsfunktionen zu notieren oder die logische Äquivalenz zweier Ausdrücke aufzuschreiben:

Standardmäßig kann LaTeX solche Zeichen nicht setzen. Man kann es ihm aber sehr einfach beibringen, indem man das Paket mathabx installiert, das man bei CTAN herunterladen kann. Dieses unterstützt gigantisch viele Zeichen, wie man der Übersicht [PDF] entnehmen kann.

Beweise

In den unterschiedlichen Kalkülen, die man in der Logik behandelt, hat sich eine besondere Schreibweise für Beweise eingebürgert. Von Hand sind diese recht leicht zu schreiben, am Computer werden sie aber schnell zu einer Qual.

Hier kann man sich des Pakets **proof** bedienen, das man ebenfalls bei CTAN bekommen kann. Nach der Installation und Einbindung in sein LaTeX Dokument kann man nun folgende Befehle benutzen:

• \infer
• \infer[Beschriftung]
• \infer*
• \infer*[Beschriftung]

Dabei ist die Folgerung immer das, was unter dem Strich steht, und der Ursprung das darüber. Wenn man neben dem Beweis eine Annotation haben möchte, kann man sich der eckigen Klammern bedienen. Setzt man hinter den Befehl einen Stern, wird statt der horizontalen Trennlinie eine vertikale gepunktete Linie dargestellt.

Um größere Beweise zusammenzubauen, muss man mehrere dieser Anweisungen in einander stapeln. Hat man mehrere Ursprungsterme, muss man diese mit einem Ampersand (&) trennen. Ein kleines Beispiel:

\\infer[\\rightarrow RAA]{\\psi}{
  \\infer{\\bot}{
    \\neg \\varphi &
    \\varphi
  }
}

Erhalten würde man damit folgende Darstellung:

Gliederungsbäume

Manchmal zerlegt man Aussagen mittels eines Gliederungsbaums. Um diese darzustellen, gibt es eine ganze Reihe von brauchbaren Paketen. Ich persönlich bevorzuge inzwischen zu diesem Zweck synttree, das relativ einfach zu bedienen ist. Man muss einfach nur die Verschachtelung des Baums in folgender Art und Weise aufschreiben:

\\synttree[$\\wedge$ [$\\neg$ [a]] [$\\vee$ [e] [f]]]

Dabei bekommt man von LaTeX dann folgendes Ergebnis:

Programmieren ist definitiv ein wichtiger Teil des Informatik- und damit auch des Bioinformatik-Studiums. Immernoch sehr beliebt ist hierbei die Sprache Java, mit der sich in Tübingen jeder (Bio-)Informatik-Student irgendwann einmal herumschlagen muss. Viele greifen dabei zur IDE eclipse, doch annähernd genauso viele wissen garnicht, was man mit eclipse alles machen kann und dieses Programm zu mehr macht als nur einem relativ langsamen und überladenen Texteditor.

Wenn man nämlich mal an dem Punkt angelangt ist, dass der Compiler sich nicht mehr über irgendwelche Syntaxfehler beklagt, dann kommt man oft in die Situation, dass sich bei der Ausführung Probleme ergeben, wie beispielsweise die immer wieder sehr beliebte “ArrayIndexOutOfBoundsException”, die den Programmierer darauf hinweist, dass er irgendwo einen Denkfehler gemacht hat und auf etwas zugreifen will, das nicht existiert. Und hier wird es jetzt interessant, denn eclipse bietet mit seinem Debugger eine gute Möglichkeit, um solchen Fehlern ein wenig auf den Zahn zu fühlen. Wenn jetzt Fragezeichen aufgetaucht sind und die Frage “Was zum Geier ist ein Debugger?” im Raum steht, spätestens dann lohnt es sich jetzt hier weiterzulesen.

Was kann der Debugger?

Wenn ein Programm ausgeführt wird (also von der Java Virtual Machine interpretiert wird), dann läuft es einfach so lange durch, bis es entweder fertig ist oder einen Fehler produziert. Mittels des Debuggers kann man das Programm gezielt während der Ausführung anhalten und einen Blick ins Innere der Virtual Machine werfen. Konkret heißt das, dass man beispielsweise die Variablenbelegungen zum Zeit der Ausführung begutachten kann.

Wie starte ich den Debugger?

Zuerst mal muss man sich klarmachen, dass es nur dann Sinn macht den Debugger zu starten, wenn man eine grobe Idee hat, wo man genauer hinschauen will. Wenn man nämlich einfach direkt statt auf “Run” auf “Debug” drückt, um das Programm auszuführen, passiert nichts Besonderes, sondern es wird eben einfach das Programm ausgeführt und nach der Ausführung beendet. Das ist natürlich nicht der Sinn der Sache.

Bevor man den Debugger startet muss man einen oder mehrere sogenannte Breakpoints setzen. Das sind Haltepunkte, an denen der Debugger die Ausführung unterbricht und uns den Blick ins Innere ermöglicht. Um solche Haltepunkte zu setzen, gibt es in eclipse mehrere Möglichkeiten. Die einfachste ist, neben der Zeile, in der man anhalten möchte, auf die Leiste einen Doppelklick zu machen, die normalerweise die Symbole für Warnungen und Fehler enhält. Dort erscheint dann ein blauer Punkt.

Solche Punkte kann man soviele setzen, wie man möchte. Wenn man sie mit einem Rechtsklick erwischt, dann gibt es in diesem Menü auch die Möglichkeit Breakpoints zu deaktivieren. Das ist während eines Debugvorgangs oft die bessere Idee als den Punkt direkt wieder zu entfernen.

Nun ist es an der Zeit den Debugger zu starten. Dies geht über das Symbol “Debug” direkt neben dem Icon “Run”, mit dem man normalerweise die Ausführung des Programms veranlasst. (Passenderweise ist das Icon mit einem Käfer versehen.) Wenn man einfach auf den Button klickt, wird der Debugger mit der zuletzt verwendeten Einstellung aus dem “Run”-Menü gestartet. Man kann auch direkt auswählen, dass man als Java-Applikation debuggen möchte. Das geht absolut äquivalent wie das simple Starten des Programms:

Wenn man einen Breakpoint gesetzt hat, dann fragt eclipse während der Ausführung, ob man in die “Debug-Perspektive” wechseln möchte. Das sollte man bestätigen und am besten direkt auch den Haken setzen, damit eclipse nicht wieder nachfragt. Nun erscheint eine neue Übersicht, die viel mehr Informationen enthält, als die vorherige. Um zur einfachen Ansicht zurückzukehren, kann man oben rechts auf “Java” klicken. Jetzt mal eine kurze Erklärung zu den einzelnen Komponenten von links oben nach rechts unten:

• Debug:
  Dieser Bereich enthält den Stack der aktuellen Ausführung. Aus diesem Fensterchen kann man ersehen, welche Methoden gerade im Moment aufgerufen wurden und dazu geführt haben, dass der aktuelle Breakpoint erreicht wurde. Außerdem findet man hier die Schaltfläche (grüner Pfeil nach rechts), mit dem man den nächsten Auswertungsschritt einleiten kann, sowie den Button, um die Ausführung abzubrechen (rotes Quadrat).
• Variables:
  Der vielleicht interessanteste Teil der Debug-Perspektive. Hier kann man sich die zum aktuellen Ausführungszeitpunkt belegten Variablen und natürlich die Werte anschauen.
• Quelltext:
  Das ist ja nichts Neues bis auf die Tatsache, dass hier immer die aktuelle Zeile hervorgehoben wird, in der die Ausführung angehalten wurde. Hier kann man auch noch während des Debuggens Breakpoints setzen und entfernen. Veränderungen am Code wirken sich allerdings erst nach einem Neustart des Debuggers aus.
• Outline:
  Ebenfalls ein bekanntes Element aus der üblichen Java-Perspektive.

Über die Möglichkeit schrittweise durch die Ausführung einer Schleife genau zu verfolgen, was mit den Werten passiert etc., kann man meistens sehr gut Fehlerquellen ermitteln, die man vielleicht vorher nicht bedacht hat. Auch bei Rekursionen kann das sehr nützlich sein, da im “Debug”-Fenster als Stack aufgezeigt wird, welche Methoden aufgerufen wurden und man sich so genauer ein Bild davon machen kann, was genau der Quelltext, den man zwar selber verfasst, aber vielleicht nicht ganz verstanden hat, eigentlich wirklich auslöst.

Zum Schluss kann ich nur empfehlen einfach mal mit dem Debugger herumzuspielen und vielleicht auch mal gezielt ein paar Fehler zu verursachen und sie zu beobachten. Während des normalen Programmierens treten zwar normalerweise auch genug Fehler auf, um Routine zu bekommen im Debuggen, aber da sollte es nach Möglichkeit dann schon etwas leichter von der Hand gehen, da man doch eher nicht die Zeit oder den Nerv hat sich mit den Details des Debuggers auseinanderzusetzen.

Wenn noch Fragen offen geblieben sind, dann nutzt doch einfach die Kommentar-Funktion hier im Blog oder schreibt mir eine eMail mit euren Anregungen.

Viel Erfolg beim Debuggen.