Keine Variablen? Wie kann ich dann ohne Variablen x + y rechnen, wenn z.B. x=3 und y=2?

Da wir nur Funktionen zur Verfügung haben, erstellen wir für die Addition einfach 3 Funktionen:
1. Funktion mit dem Namen x:

function x() { return 3; }

2. Funktion mit dem Namen y:

function y() { return 2; }

3. Funktion mit dem Namen +:

function plus($x,$y) { return $x + $y; }
function result() { return plus(x(),y()); }

Die Funktionen x und y sind daher Funktionen, die immer einen bestimmten konstanten Wert zurückgeben. Dieser Wert kann jedoch im Gegensatz zu Variablen nicht mehr geändert werden. Das Ergebnis result ist durch den Aufruf der Funktion plus mit den Parametern x und y definiert. Wir haben also die Berechnung ohne Variablen durchgeführt. Natürlich ist eine derartige Konstruktion in PHP nur bedingt sinnvoll, soll aber zeigen, dass der Verzicht auf Variablen auch grundsätzlich in PHP technisch möglich ist.

Keine Zustände oder globalen Variablen?

In der funktionalen Welt ist es sehr wichtig, dass Funktionen beim Aufruf mit gleichen Parametern (Input) immer den selben Wert zurückliefern (Output). Egal zu welchen Zeitpunkt im Programm oder auf welchem Rechner ausgeführt, muss eine Funktion bei einem bestimmten Input immer den selben Output haben.

$GLOBALS['einwert'] = 0;
function garNichtFunktional($x) {
  $GLOBALS['einwert'] += 1;
  return $x + $GLOBALS['einwert'];
}

Bei dieser Funktion wird bei zwei aufeinander folgenden Aufrufen nicht der selbe Rückgabewert errechnet, da sich zwischen zwei Aufrufen der globale Wert einwert ändert. So liefert garNichtFunktional(4) zuerst 5 als Ergebnis und bei einem erneuten Aufruf das Ergebnis 6. Die Funktion wird in diesem Beispiel von außen (der globalen Variable) beinflusst. Genau aus diesem Grund, um eine Abhängigkeit von einem Bereich außerhalb der Funktion zu verhindern, ist es ebenfalls nicht möglich, eine Referenz als Parameter zu übergeben. Erhält eine Funktion eine Referenz, könnte die Funktion einen Zustand/Wert außerhalb ihres Bereiches über die Referenz verändern und damit andere Funktionen bzw. Zustände beeinflussen. Diese Veränderung von Bereichen außerhalb der Funktion ist unter dem Begriff Seiteneffekte bekannt. Um Seiteneffekte zu verhindern, wird daher nur das Call-by-Value Konzept angewandt. Eine Funktion kann daher nur über die Parameter und dem Return-Wert mit der “Außenwelt” kommunizieren.

Keine Schleifen?

Da Schleifen Zählvariablen besitzen, sind diese in strengen funktionalen Konzepten ebenfalls nicht erlaubt. Ersetzt wird die Mächtigkeit von Schleifen durch die Rekursion. Die folgende while Schleife

$x = 1;
while ($x <= 10) {
  $x += 1;
}

kann zum Beispiel rekursiv durch die folgende Funktion abgebildet werden.

function bisZehn($x) {
  if ($x >= 10) return $x;
  else return bisZehn($x+1);
}
$x = bisZehn(1);

Funktionen als Parameter?

Da es keine klassischen Variablen gibt und jeder Ausdruck als auswertbare Funktion angesehen wird, können als Parameter nur Funktionen übergeben werden. Dieses Feature (sogenannte Funktionen höherer Ordnung oder Higher-Order Functions) ist auch seit der PHP Version 5.3 vorhanden und ermöglicht zum Beispiel folgende Konstrukte:

function array_map($array,$funktion) {
  for ($i=0; $i < count($array); $i++) {
    $array[$i] = $funktion($array[$i]);
  }
  return $array;
}

//oder streng funktional ohne for Schleife mit Rekursion implementiert

function array_map($array,$funktion,$index) {
  if ($index >= count($array)) {
    return array();
  }
  return array_merge(
    array($funktion($array[$index])),
    array_map($array,$funktion,$index+1)
  );
}

array_map($mein_array,function($element) { return $element+5; },0);
array_map($mein_array,function($element) { return md5($element); },0);

Die Funktion array_map wendet dabei eine beliebige übergebene Funktion auf das übergebene Array an. Der erste Aufruf würde zum Beispiel zu jedem Element 5 addieren. Der zweite Aufruf übergibt eine anonyme Funktion, die den md5 Hash Wert für einen Parameter $element berechnet, und liefert daher als Gesamtergebnis das Array mit den md5 Hash Werten der originalen Array-Elemente.
Der große Vorteil besteht hierbei in der flexiblen Wiederverwendbarkeit der Funktion array_map. Diese kann mit beliebigen Funktionen kombiniert werden und spart viel Programmierarbeit. Natürlich ist es nicht sinnvoll in PHP streng funktional zu programmieren und keine Schleifen und Variablen mehr zu verwenden. Auch im Beispiel der Funktion array_map ist ersichtlich, dass der rein funktionale Code nicht unbedingt einfacher und verständlicher wird. Funktionale Sprachen sind dagegen für das funktionale Paradigma optimiert, wie das folgende Beispiel derselben Funktion array_map in der funktionalen Programmiersprache OCaml zeigt.

let rec array_map my_fun = function
| [ ] -> [ ]
| x::xs -> [my_fun x] @ array_map my_fun xs;;

OCaml Code Erklärung: Die | Zeilen dienen hierbei als Vergleichsstruktur (Pattern Matching) und funktionieren ähnlich wie ein switch Befehl. Ist das übergebene Array (bzw. in diesem Fall eine Liste) leer, entspricht also [ ], wird eine leere Liste zurückgegeben. Sind noch Elemente in der Liste, wird diese in das erste Element (x) und eine Restliste (xs) aufgetrennt. Auf das erste Element wird die übergebene Funktion my_fun angewandt und die Funktion array_map rekursiv mit der Restliste aufgerufen. Das Symbol @ verbindet zwei Listen und führt in dem Beispiel die resultierenden Listen der rekursiven Aufrufe zusammen. Das Ergebnis ist eine Liste, in der auf alle ursprünglichen Elemente die übergebene Funktion my_fun angewandt wurde.

Was bringts?

Bisher waren funktionale Programmiersprachen vor allem in der akademischen Welt anzutreffen, da sie der Mathematik sehr nahe stehen und daher im wissenschaftlichen Bereich oft Anwendung finden. Klassische Vertreter sind Haskell, Erlang, OCaml, Scala, Scheme, Lisp, aber auch moderne Sprachen wie zum Beispiel PHP, integrieren Features der funktionalen Welt. Einen wichtigen Beitrag zur Verbreitung hat sicher auch JavaScript geleistet, da hier stark auf funktionale Sprachkonstrukte zurückgegriffen wird.
Doch welche Vorteile ergeben sich durch die Verwendung von funktionalen Sprachen bzw. ihren Features?
Die Verwendung von Funktionen als Parameter (Higher-Order Functions) ist eine der wichtigsten Funktionalitäten, die einem das Programmierleben stark vereinfachen können. Sie sind meist wesentlich flexibler und können daher öfters im Programmcode wiederverwendet werden. Zusätzlich ist es möglich, komplexe Abläufe zu abstrahieren und dann in beliebigen Bereichen wiederzuverwenden. Dank PHP 5.3 ist das nun auch für den PHP Programmierer möglich.
Das funktionale Konzept ist auch keineswegs nur ein akademisches Hirngespinst, sondern ist seit langer Zeit auch im produktiven Einsatz (z.B. Anwendungen in der Telekommunikation mit Erlang) anzutreffen.
Ein weiterer Vorteil, der vor allem durch die starke Zunahme der Parallelrechner (Quad-Core ist bereits im Consumer-Bereich der Standard) immer wichtiger wird, ist die einfache Möglichkeit zur Parallelisierung. Da in streng funktionalen Programmiersprachen keine Seiteneffekte auftreten können, kann eine Funktion unabhängig vom restlichen Programm zum Beispiel auf einem anderen Prozessor oder Rechner ausgeführt werden. Auch Google bedient sich mit dem MapReduce Konzept (beschrieben im phphatesme Artikel …und das Leben nach SQL geht weiter … jetzt wird reduziert!) diesem Vorteil und vereinfacht so die Verteilung von Tasks (z.B. Suchindexerzeugung) über mehrere tausend Server hinweg.
Auch die laufende Integration von funktionalen Sprachfeatures in aktuellen modernen Programmiersprachen zeigt zusätzlich, dass es sich hierbei um ein gelungenes Konzept handelt, das die Programmierung stark vereinfachen kann. Eine tiefere Auseinandersetzung mit diesem Thema ist also auch für den klassischen PHP Programmierer sinnvoll und erweitert nicht nur den imperativen Tellerrand, sondern ermöglicht auch eine Verbesserung des Programmierstils bzw. Ausnützung modernen Sprachfeatures in PHP. PHPhatesme plant ebenfalls weitere Beiträge zu diesem Thema – über Anregungen und Input freuen wir uns natürlich auch in den Kommentaren.

Hier wie immer noch einige weiterführende Links:

• Wikipedia: Funktionale Programmierung
• Functional PHP 5.3
• Unterlagen zur funktionalen Programmierung der Universität Wien, Universität Innsbruck

Zuerst möchte ich die Definitions eines gerichteten Baums ins Gedächtnis rufen, damit keine Missverständnisse auftreten: Ein gerichteter Baum, dessen Kantenrichtung zu den Blättern zeigt, ist ein Graph, bei dem es für jeden Knoten x genau einen Pfad von der Wurzel zu x gibt. Bereits aus der Definition ergibt sich eine Eigenschaft, die bei der Suche hilft: Wenn zu jedem Knoten nur ein Pfad existiert, dann kann man nach einem Traversierungsschritt die Knoten, die nicht in derselben Richtung liegen, nicht mehr erreichen (ohne einen Schritt zurückzugehen), womit der Suchraum bei jedem Schritt auf ein Minimum reduziert wird. Optimalerweise wird der Baum derart strukturiert, dass man bei der Traversierung des Baums sofort den richtigen Weg geht, sodass man bei einer Baumhöhe h insgesamt O(h) Schritte zum Suchen eines Schlüssels benötigt, womit der o.g. Vorteil zum Tragen kommt. Eine weitere hilfreiche Eigenschaft ist die Kreisfreiheit, die sich leicht aus der Definition eines Baums folgern lässt. Durch diese Kreisfreiheit kann man die verschiedenen Operationen auf Bäumen sehr einfach rekursiv implementieren, ohne Endlosschleifen zu provozieren, was vor allem Organisationsaufwand spart.

Der Unterschied zwischen Bäumen und Suchbäumen besteht vor allem in ihrer Struktur, denn Suchbäume sind derart strukturiert, dass sich die drei Operationen insert, find und delete effizient auf ihnen implementieren lassen. Bei den gängigsten Arten von Suchbäumen wird die Struktur anhand einer Ordnung auf den Schlüsseln festgelegt. Meist handelt es sich dabei um eine sog. Totalordnung, die wir nachfolgend mit ≤ bezeichnen. Ein Beispiel für eine solche Totalordnung ist die ≤-Relation auf den natürlichen Zahlen. Nimmt man also die Menge der natürlichen Zahlen als Schlüsselmenge, so muss man nur noch den ≤-Vergleichsoperator der jeweiligen Programmiersprache benutzen und schon basiert der Baum auf einer Totalordnung. Benötigt wird eine solche Ordnung, um anhand des gesuchten Schlüssels und des Schlüssels des aktuell besuchten Knotens entscheiden zu können, wo die Suche fortgesetzt werden muss. Als Beispiel wähle ich den binären Suchbaum, der beim nächsten akademischen Tag unter die Lupe genommen wird:

1. Ist x ≤ y und y ≤ x, d.h. x = y, dann ist die Suche beendet.
2. Ist x ≤ y, wird die Suche im linken Teilbaum fortgesetzt.
3. Ist y ≤ x, wird die Suche im rechten Teilbaum fortgesetzt.

Da dies ein Artikel für den akademischen Tag ist, geben wir uns nicht mit dem Nennen von Begriffen zufrieden, sondern erläutern, was eine Totalordnung ist, damit wir Suchbäume nicht nur für natürlich aussehende Schlüsselmengen wie Zahlen verwenden können, sondern auch für komplexere Schlüssel.  Die lexikographische Ordnung von Zeichenketten wäre ein weiteres Beispiel, aber auch Arrays könnten als Schlüsselmengen verwendet werden, sofern man eine Totalordnung dafür angibt. Damit man weiß, ob man eine Totalordnung gefunden hat, definieren wir eine Totalordnung.

Für eine Totalordnung ≤ auf einer beliebigen Menge M gelten folgende Gesetze:

• ≤ ist reflexiv :⇔ ∀ x ∈ M: x ≤ x
  • Jedes Element ist kleiner-gleich sich selbst.
• ≤ ist antisymmetrisch :⇔ ∀ x,y ∈ M: x ≤ y und y ≤ x ⇒ y = x
  • Bsp.: Wenn 42 ≤ y und y ≤ 42, dann ist folglich 42 = y.
• ≤ ist transitiv :⇔ ∀ x,y,z ∈ M: x ≤ y und y ≤ z ⇒ x ≤ z
  • Bsp.: Wenn 1 ≤ 2 und 2 ≤ 3, dann ist folglich 1 ≤ 3.
• ≤ ist total :⇔ ∀ x,y ∈ M: x ≤ y oder y ≤ x
  • Alle Elemente sind miteinander vergleichbar.
  • Bsp.: 21 ≤ 42 oder 42 ≤ 21.

Nehmen wir an, eines dieser Gesetze würde nicht gelten, dann gäbe es an verschiedenen Stellen solcher Suchbäume Probleme:

• ≤ ist nicht reflexiv: Da x ≤ x und x ≤ x nicht gelten, kann x = x nicht gefolgert werden, weshalb man  nicht erkennen würde, wenn man den gesuchten Schlüssel gefunden hat.
• ≤ ist nicht antisymmetrisch: Da sich x = y nicht aus x ≤ y und y ≤ x folgern ließe, wüsste man nicht, ob man den gesuchten Schlüssel gefunden hat oder in welchen Teilbaum man weitersuchen muss.
• ≤ ist nicht total: Es gibt ein Paar x, y für das weder x ≤ y noch y ≤ x gilt. Man kann also weder entscheiden, ob der gesuchte Schlüssel gefunden wurde, noch in welchem Teilbaum man weitersuchen muss.
• ≤ ist nicht transitiv: Sei x ≤ y und y ≤ z, aber es gelte nicht x ≤ z. Dann ist ≤ entweder nicht total oder es gilt stattdessen z ≤ x. Da ≤ jedoch total sein soll, betrachten wir den Fall  z ≤ x. D.h. es würde gelten x ≤ y ≤ z ≥ x, bedeuten würde, dass x im rechten und im linken Teilbaum vom Baum mit der Wurzel z zu finden sein könnte. Vor allem beim Umstrukturierungen des Baums, beispielsweise durch Löschen oder Rotation, könnte das zu Fehlern führen.

Es gibt einige bekannte Suchbäume, die ich nachfolgend nennen und kurz beschreiben möchte:

• Binärer Suchbaum: Basiert auf der Eigenschaft, dass alle Schlüssel des linken Teilbaums kleiner als der Schlüssel der Wurzel sind und alle Schlüssel des rechten Teilbaums größer als der o.g. Schlüssel sind.
• AVL-Baum: Erweitert den binären Suchbaum um Rotationen, die ggf. beim Einfügen oder Löschen von Elementen durchgeführt werden, damit
• Rot-Schwarz-Baum: Bei diesem Baum hat jeder Knoten eine Farbe (rot oder schwarz) für die einige Regeln gelten, durch die sichergestellt wird, dass man O(log n) Schritte zum Finden eines beliebigen Schlüssels benötigt.
• B-Baum: Im Gegensatz zu den bereits genannten Bäumen ist dieser Baum nicht binär, d.h. er kann mehr als zwei Kindknoten haben, wodurch er flacher ist. In jedem Knoten befinden sich weitere Informationen, anhand derer er feststellen kann, welcher Knoten als nächstes besucht werden muss.
• Präfixbaum: Hierbei handelt es sich um einen speziellen Suchbaum, bei dem der Schlüssel in Einzelteile zerlegt wird, um daraus die Struktur des Baums zu bestimmen. Bei  Schlüsseln, die nur aus Ziffern bestehen, hätte der Baum einen Verzweigungsgrad von 10, da eine Zahl in seine Bestandteile (Ziffern) zerlegt wird. Das Suchen nach einer n-stelligen Zahl würde dann n Schritte im Baum benötigen.

Im Vergleich zu Hashmaps sind Bäume meist langsamer, aber dafür wird der Platz besser ausgenutzt und sie sind robuster, wenn es sich um Ausnahmefälle handelt. Natürlich lassen sich beide Techniken miteinander kombinieren, aber im Endeffekt kommt es auf den Anwendungsfall an, ob Bäume oder Hashmaps zu bevorzugen sind. Beispielsweise sind Hashmaps in Datenbanken quasi nicht nutzbar, da die Datenmengen häufig größer sind als der Arbeitsspeicher Platz bietet. Da die meisten Daten deshalb auf der Festplatte gespeichert werden müssen, kommt der B-Baum zum Einsatz, der durch seine geringe Höhe ein Minimum an Festplattenzugriff garantiert.

Der Begriff setzt sich aus den beiden englischen Begriffen hash, der eine Hashfunktion bezeichnet, und map (dt. Abbildung) zusammen. Geläufiger dürfte die Bezeichnung Funktion für eine (mathematische) Abbildung sein. Was versteht man unter Funktion? Eine Beziehung zwischen zwei Mengen, dem Definitions- und dem Wertebereich.  Dabei ordnet eine Funktion jedem Element des Definitionsbereichs genau ein Element aus dem Wertebereich zu. In der Schule werden zur Beschreibung von Funktionen häufig Tabellen benutzt, um diese Relationen zu beschreiben. Dadurch erschließt sich auch der deutsche Begriff Hashtabelle.

Nicht nur der Begriff Hashmap, sondern auch die Datenstruktur Hashmap setzt sich aus einer Abbildung und einer Hashfunktion zusammen. In diesem Kontext bezeichnen wir den Definitionsbereich als Schlüsselmenge und den Wertebereich als Objektmenge. D.h. die Funktion bildet einen Schlüssel auf ein Objekt ab. Der Begriff Objekt ist hierbei nicht zu verwechseln mit dem gleichnamigen objektorientierten Konzept. Deshalb kann die Objektmenge natürlich auch skalare Objekte, z.B. Strings, enthalten. Da wir nun wissen, welchen Zweck man mit einer Hashmap verfolgt, nämlich das Speichern und Auslesen von Objekten anhand von Schlüsseln, können wir dazu übergehen, wie eine Hashmap implementiert wird. Hierfür ist die bereits erwähnte Hashfunktion der Namensgeber. Um Missverständnisse zu vermeiden, muss noch geklärt werden, was eine Hashfunktion ist: Eine Funktion, die einem Objekt einen numerischen Wert zuordnet. Das prominente Beispiel hierfür ist die Funktion md5, die einem String einen hexadezimalen Wert zuordnet. In PHP könnte man eine Hashfunktion schreiben, die eine Variable $obj auf hexdec(md5(serialize($obj))) abbildet. Durch die Serialisierung wird sichergestellt, dass md5 den MD5-Hash des Objekts berechnen kann. Da der Rückgabewert von md5 hexadezimal ist, ist die Funktion hexdec notwendig, um dem hexadezimalen Wert den gleichen dezimalen Wert zuzuordnen.

Nachdem wir die begrifflichen Voraussetzungen geschaffen haben, wird es Zeit, die Verwendung der Hashfunktion zu erläutern. Wir benutzen die Hashfunktion, die nachfolgend mit hash bezeichnet wird, um den Speicherort eines Objekts anhand seines Schlüssels zu bestimmen. Hierfür werden Arrays mit numerischen Indizes, wie z.B. SplFixedArray, verwendet. Damit diese Zuordnung funktioniert, ist es notwendig, dass das Array stets dieselbe Länge hat. Angenommen, die Länge sei mit n begrenzt, dann suchen wir eine Funktion f, die jedem Element der Schlüsselmenge ein Element aus {0, …, n-1} zuordnet. f ließe sich dann folgendermaßen definieren: f(key) = hash(key) modulo n. D.h. erst wird der Hash eines Schlüssels generiert und anschließend wird modulo n, d.h. der Rest bei einer ganzzahligen Division durch n, berechnet. Durch die modulo-Operation ergibt sich auch die Einschränkung der konstanten Länge des Arrays. Mit f haben wir nun eine Funktion gefunden, die jedem Schlüssel einen Speicherort im Array zuweist. Da diese Funktion O(1)-Schritte zum Berechnen der Position benötigt, lassen sich auch die beiden Operationen zum Einfügen und Auslesen von Objekten in O(1) realisieren. Die Schritte beim Einfügen und Auslesen können folgendermaßen zusammengefasst werden:

• insert(key, obj):
  1. Position p anhand von f(key) berechnen.
  2. obj an Position p schreiben.
• read(key):
  1. Position p anhand von f(key) berechnen.
  2. Lesen an Position p und ggf. Objekt zurückgeben.

Dieser Algorithmus und die obere Schranke gelten allerdings nur für den besten Fall, in dem keine sog. Kollisionen auftreten. Bei einer Kollision erhalten zwei Schlüssel dieselbe Position innerhalb des Arrays. Um dieses Problem zu lösen, gibt es zwei gängige Verfahren: Hashing mit Verkettung und Hashing mit offener Adressierung.

Beim Hashing mit Verkettung enthält jedes Array-Element sog. Buckets (dt. Behälter), in denen die kollidierten Objekte mitsamt Schlüssel enthalten sind. Im trivialen Fall handelt es bei den Buckets um Arrays, aber natürlich sind auch komplexere Datenstrukturen wie Suchbäume möglich. Die Prozeduren zum Einfügen und Auslesen müssen dann folgendermaßen modifiziert werden:

• insert(key, obj):
  1. Position p anhand von f(key) berechnen.
  2. Wenn key im Bucket der Position p existiert, wird das Paar (key, obj) aktualisiert, ansonsten wird es eingefügt.
• read(key):
  1. Position p anhand von f(key) berechnen.
  2. Wenn key im Bucket der Position p existiert, wird das zugehörige Objekt zurückgegeben.

Im schlimmsten Fall sind alle Elemente der Hashmap in einem Bucket, womit sich die Komplexität verschlechtert, z.B. auf O(log n) bei guten Suchbäumen.

Eine Alternative stellt das Hashing mit offener Adressierung dar. Hierbei wird eine weitere Funktion g eingeführt, die zum Generieren einer Folge von Positionen verwendet wird. Die einfachste Funktion dieser Bauart ist die sog. Nachfolgerfunktion, die einer Zahl seinen Nachfolger zuordnet. Bei diesem Verfahren enthält jedes Array-Element nur das Objekt mitsamt Schlüssel. Natürlich müssen die Prozeduren zum Einfügen und Auslesen auch für diese Strategie angepasst werden.

• insert(key, obj):
  1. Position p anhand von f(key) berechnen.
  2. Ist das Array an Position p leer, so wird (key, obj) an Position p eingefügt und die Prozedur beendet.
  3. Passt der Schlüssel an Position p zu key, so wird das vorhandene Objekt durch obj ersetzt und die Prozedur beendet.
  4. Setze p = g(p) modulo n.
  5. Fahre bei 2. fort.
• read(key):
  1. Position p anhand von f(key) berechnen.
  2. Ist das Array an Position p leer, so wird null zurückgegeben.
  3. Passt der Schlüssel an Position p zu key, so wird das Objekt an Position p zurückgegeben.
  4. Setze p = g(p) modulo n.
  5. Fahre bei Schritt 2 fort.

Wie man sieht, ist hier eine Endlosschleife möglich. Dieser Fall kann auftreten, wenn eine ungünstige Funktion g, wie z.B. die identische Funktion id mit id(x) = x, gewählt wurde, oder alle Positionen des Arrays bereits besetzt sind.  Zum Verhindern der zuletzt genannten Situation, kann man das Array vergrößern und die enthaltenen Elemente umordnen. Auch beim Hashing mit Verkettung ist das Vergrößern des Arrays sinnvoll, da man damit die Anzahl der Kollisionen reduziert und somit im Mittel eine geringere Zugriffszeit erhält.

Resümierend lässt sich sagen, dass Hashmaps aufgrund der bestmöglichen Best-Case-Laufzeit von O(1) und einer Worst-Case-Laufzeit von O(log n) bzw. O(n) zu den schnellsten Datenstrukturen zählen. Dieser Vorteil wird durch die Nutzung einer geeigneten Hashfunktion realisiert, mit der das Suchen im günstigsten Fall nicht notwendig ist, da sich die Position im Array in einem konstanten Schritt berechnen lässt. Eben diese Funktion fehlt noch für eine effiziente Implementierung in nativem PHP, wohingegen die restlichen Strategien ausreichend beschrieben wurden, um sie implementieren zu können.

Der Einfachheit halber werde ich Breiten- und Tiefensuche nur auf folgenden Graphen anwenden:

Beispielgraph

Es handelt sich dabei um einen ungerichteten und zusammenhängenden Graphen. Die Verwendung eines ungerichteten Graphen macht dabei keinen wesentlichen Unterschied, da die gesamte Argumentation sehr leicht auf gerichtete Graphen übertragen werden kann. Für einen ungerichteten Graphen G = (V,E) bedeutet der Begriff “zusammenhängend” nichts anderes, als dass für je zwei Knoten v, w ∈ V (mindestens) einen Pfad von v nach w bzw. von w nach v existiert. Der Vollständigkeit halber sollte noch eine Definition für einen Pfad angegeben werden: Ein Pfad ist ein Tupel (v₁, v₂, …, v_n) mit {{v₁,v₂}, {v₂,v₃}, …, {v_n-1, v_n}} ⊆ E und v_i ≠ v_j für i ≠ j. Anschaulich: Ein Pfad ist eine Folge von unterschiedlichen Knoten, bei dem für alle benachbarten Knoten gilt, dass sie miteinander verbunden sind. Da Breiten- und Tiefensuche in PHP implementiert werden, bietet es sich an, den Beispielgraphen als Adjazenzliste in PHP-Code darzustellen:

$adj = array(
	'A' => array('B','C','D'),
	'B' => array('A','E','H'),
	'C' => array('A','D','F','G'),
	'D' => array('A','C','E','G','H','I'),
	'E' => array('B','D','H'),
	'F' => array('C','G','I'),
	'G' => array('C','D','F','I'),
	'H' => array('B','D','E','I'),
	'I' => array('D','F','G','H')
);

Traversiert man einen Graphen, so erhält man eine Traversierungsreihenfolge und einen Traversierungsbaum. Zwar ist der Begriff eines Baums geläufig, aber dennoch möchte ich ihn präzise definieren: Ein ungerichteter Baum ist ein Graph, bei dem es zwischen je zwei Knoten x und y genau einen Pfad von x nach y bzw. von y nach x gibt. Diese Definition lässt sich leicht auf gerichtete Graphen übertragen: Ein gerichteter Baum, dessen Kantenrichtung zu den Blättern zeigt, ist ein Graph, bei dem es für jeden Knoten x genau einen Pfad von der Wurzel zu x gibt. Blätter sind hierbei die Knoten, die keine ausgehende Kanten haben, und die Wurzel ist der (einzige) Knoten, der keine eingehende Kante hat.

Nachdem alle für das Verständnis notwendigen Begriffe erläutert wurden, können wir mit der Breitensuche (engl. Breadth First Search) beginnen, die im vorangegangen Artikel bereits erwähnt wurde. Der Einfachheit halber wird die BFS-Prozedur, die ich vorstelle, lediglich die Reihenfolge der Knoten darstellen, in der sie besucht wurden – also das Aufstellen der Traversierungsreihenfolge.

Das Herz der BFS-Prozedur ist die Verwendung einer Warteschlange (SplQueue), die nach dem FIFO-Prinzip arbeitet, d.h. für je zwei Knoten, die in die Warteschlange eingefügt wurden, gilt, dass derjenige, der vorher eingefügt wurde, auch vor dem anderen Knoten entnommen wird. Dadurch entsteht das Verhalten, das man als Breitensuche charakterisiert: Wird ein Knoten bearbeitet, so werden alle seine benachbarten (und noch nicht besuchten) Knoten der Breite nach in die Warteschlange eingefügt und sie werden später in derselben Reihenfolge entnommen.

Natürlich benötigt die BFS-Prozedur nicht nur einen Graphen, auf dem sie ausgeführt werden soll, sondern auch einen Startknoten, der mit $start bezeichnet wird.

function bfs ($adj, $start) {
	$const = function($val) { return function($x) use ($val) { return $val; };};
	$base = array_flip(array_keys($adj));
	$result = array_map($const(0), $base);
	$visited = array_map($const(false), $base);

	$queue = new SplQueue();
	$queue->enqueue($start);
	$visited[$start] = true;
	$number = 1;

	foreach($queue as $item) {
		$result[$item] = $number++;

		foreach($adj[$item] as $next) {
			if(!$visited[$next]) {
				$queue->enqueue($next);
				$visited[$next] = true;
			}
		}
	}

	return $result;
}

bfs($adj, ‘A’) ergibt array(‘A’ => 1, ‘B’ => 2, ‘C’ => 3, ‘D’ => 4, ‘E’ => 5, ‘F’ => 7, ‘G’ => 8, ‘H’ => 6, ‘I’ => 9). Aber nicht nur die BFS-Nummerierung, sondern auch der sog. Traversierungsbaum ist interessant. Die Kantenrelation dieses Baums lässt sich folgendermaßen beschreiben: Eine gerichtete Kante (x,y) existiert genau dann, wenn y beim Bearbeiten von x in die Warteschlange eingefügt wurde. Dass es sich dabei um einen Baum handelt, lässt sich leicht mit der oben angegebenen Definition erklären. Da jeder Knoten genau einmal eingefügt wird, hat jeder Knoten (mit Ausnahme der Wurzel) maximal eine eingehende Kante. Dadurch kann es von der Wurzel zu jedem Knoten maximal einen Weg geben und die Existenz eines solchen Wegs ist bei einem zusammenhängenden Graphen trivialerweise erfüllt. Folglich gibt es für jeden Knoten x genau einen Weg von der Wurzel zu x.

Traversierungsbaum

Der Anschaulichkeit halber erhält jeder Knoten eine neue Bezeichnung, die sich aus seiner alten Bezeichnung und BFS-Nummerierung zusammensetzt. Auffällig ist dabei, dass die Zahlenfolge in jeder Ebene von links nach rechts aufsteigend ist. Diese Eigenschaft lässt sich verallgemeinern: Sei (w,1) die Wurzel und seien (x,n) und (y,m) zwei beliebige Knoten im Traversierungsbaum, so gilt, wenn  n < m, dann gibt es keinen Weg von w nach y, der kürzer ist als der Weg von w nach x. Weshalb gilt diese Eigenschaft? Das lässt sich aus der FIFO-Eigenschaft folgern: Beginnend mit Startknoten werden alle Knoten, die direkt mit dem Startknoten verbunden sind, in die Warteschlange eingefügt. D.h. alle Knoten in der Warteschlange haben eine Entfernung, also die Anzahl der Kanten zwischen zwei Knoten, von 1, da sie direkt mit dem Startknoten verbunden sind. Werden diese Knoten abgearbeitet, werden ans Ende der Warteschlange alle Knoten eingefügt, die eine Entfernung von 2 zum Startknoten haben. Dieses Verfahren wird solange fortgesetzt wie es Knoten in der Warteschlange gibt. Anhand dieser Eigenschaft lässt sich auch erklären, weshalb die Breitensuche das Kürzester-Weg-Problem auf ungewichteten Graphen löst. Das Kürzester-Weg-Problem lässt sich auf gewichteten Graphen übrigens sehr ähnlich lösen: Statt einer Warteschlange wird eine Prioritätswarteschlange verwendet, in der die Knoten nach der Entfernung (anhand der Kantengewichte) sortiert sind. Eine Einschränkung muss hierbei allerdings gemacht werden: Negative Kantengewichte funktionieren mit obigen Ansatz im Allgemeinen nicht. In der englischen Wikipedia finden sich weitere Anwendungen für Breitensuche.

Im Gegensatz zur Breitensuche verwendet die Tiefensuche (engl. Depth First Search) einen Stapel (SplStack) oder wird rekursiv implementiert, woraus das LIFO-Prinzip folgt. Konkret bedeutet das, dass man alle benachbarten Knoten auf einem Stapel speichert und das Element auf dem Stapel als nächsten Knoten wählt. Durch die Verwendung des Stapels liegt immer ein Knoten oben, der möglichst tief liegt. Um dabei nicht zu sehr an die Vorstellungskraft zu appellieren: Ein Knoten x liegt genau dann tiefer als y, wenn der Pfad, der zu x geführt hat, länger ist als derjenige, der zu y geführt hat. D.h. man geht solange in die Tiefe bis es nicht mehr möglich ist. Von diesem Knoten aus geht man wieder zurück, bis man zu einem Knoten gelangt, an dem man die Tiefensuche fortsetzen kann. Das lässt sich sehr schön an der DFS-Nummerierung zeigen: dfs($adj, ‘A’) gibt array(‘A’ => 1, ‘B’ => 2, ‘C’ => 5, ‘D’ => 4, ‘E’ => 3, ‘F’ => 6, ‘G’ => 7, ‘H’ => 9, ‘I’ => 8 ) zurück. Beim Nachvollziehen anhand des Beispielgraphen fällt einem noch ein anderer Sachverhalt auf: Es gibt einen Pfad, mit dem man alle Knoten erreichen kann, was im Allgemeinen nicht der Fall ist. Beispielsweise gibt es für Bäume einen ähnlichen Traversierungsbaum wie er bei der Breitensuche entstanden ist. Eine konkrete Implementierung der DFS-Prozedur könnte folgendermaßen aussehen:

function dfs ($adj, $start) {
	$const = function($val) { return function($x) use ($val) { return $val; };};
	$base = array_flip(array_keys($adj));
	$result = array_map($const(0), $base);
	$visited = array_map($const(false), $base);

	$stack = new SplStack();
	$stack->push($start);
	$number = 1;

	while(!$stack->isEmpty()) {
		$item = $stack->pop();

		if(!$visited[$item]) {
			$result[$item] = $number++;
			$visited[$item] = true;

			foreach(array_reverse($adj[$item]) as $next) {
				$stack->push($next);
			}
		}
	}

	return $result;
}

Diese Implementierung benutzt einen Stapel, um den Gegensatz zur Breitensuche bzw. der Warteschlange zu verdeutlichen. Außerdem spart man durch das Verwenden eines Stapels entweder eine weitere Funktion oder überflüssige Überprüfungen der übergebenen Werte. Weitere Unterschiede zur Breitensuche sind zum einen der Zeitpunkt der Unterscheidung, ob ein Knoten bereits besucht wurde, und zum anderen die Reihenfolge, in der die Knoten auf den Stapel gelegt werden. Die umgekehrte Reihenfolge ist zwar nicht notwendig, aber sorgt dafür, dass – analog zur Breitensuche – immer der Knoten, der in der Adjazenzliste am weitesten links steht, zuerst besucht wird. Hingegen ist der Zeitpunkt der Überprüfung essentiell für die Tiefensuche. In der Breitensuche wird ein Knoten genau dann in die Warteschlange eingefügt, wenn er noch nicht in der Warteschlange ist. Bei der Tiefensuche hingegen möchte man dieses Verhalten nicht: Befinden wir uns gerade bei der Bearbeitung von Knoten y und existiert ein (unbesuchter) Knoten x, der von y aus erreichbar ist, bereits auf dem Stapel, so bedeutet es, dass es einen Knoten z gibt, von dem x aus erreichbar ist, der aber höher als y liegt. Würde man x in diesem Fall nicht (erneut) auf den Stapel legen, würde es dem Prinzip Tiefensuche widersprechen, da man die Knoten in der Tiefe sucht. Anschaulich  könnte x = D, y = E und z = A im Beispielgraphen gelten. Nach dem ersten Schritt, also beim Knoten A, werden B, C, D auf den Stapel gelegt und bei B wird in der Tiefe gesucht. Nach einem weiteren Schritt und weiteren Knoten auf dem Stapel tritt obiges Verhalten auf, d.h. D soll beim Besuch von E auf den Stapel gelegt werden. Würde D also nicht von E aus besucht werden, würde das nicht der Tiefensuche entsprechen.

Unter den möglichen Anwendungen für die Tiefensuche möchte ich besonders den Backtracking-Algorithmus hervorheben, der sich sehr gut zum Problemlösen eignet. Zwar wird Backtracking meist nicht explizit auf einem Graphen ausgeführt, aber er arbeitet nach dem Prinzip der Tiefensuche, da er bei der Suche nach einer Lösung möglichst viele Schritte in die Tiefe geht und bei einem Fehler zur letzten Verzweigung zurückkehrt um von dort aus wieder in die Tiefe zu gehen.

Anmerkung: Der PHP-Code funktioniert aufgrund der Nutzung von Closures mit PHP 5.3 und höher. Außerdem funktionieren die Algorithmen derzeit nur auf zusammenhänden Graphen. Bei nicht zusammenhängen Graphen muss man eine weitere Schleife hinzufügen, sodass alle Knoten erfasst werden. Dabei entsteht natürlich kein Traversierungsbaum mehr, sondern ein sog. Traversierungswald – also ein Graph dessen Zusammenhangskomponenten Bäume darstellen.

Bevor wir mit der Theorie beginnen, möchte ich dieses Thema motivieren, da die Graphentheorie in sehr vielen Bereichen der Informatik eingesetzt werden kann. Sie schlägt sich innerhalb der praktischen Informatik nicht nur in Algorithmen oder Datenstrukturen (wie z.B. dem allseits bekannten Baum) nieder, sondern auch in diversen UML-Diagrammen. Das bekannte Klassendiagramm kann genauso wie ein Graph aufgefasst werden wie ein Aktivitätsdiagramm. Insgesamt lassen sich Graphen sehr gut zur Modellierung von Problemen und deren Lösung nutzen. Mithilfe der Komplexitätstheorie lässt sich sogar für einige Probleme beweisen, dass sie nicht effizient lösbar sind. Da die Graphentheorie sehr vielschichtig ist, möchte ich in diesem einführenden Artikel vor allem grundlegende Graphen erklären und darauf eingehen, wie man diese in einem Computer darstellen kann. In den weiteren Artikeln zur Graphentheorie sollen dann die o.g. Themen sowie praktische Algorithmen auf Graphen vertieft werden.

Als erstes stellt sich die Frage, was ist denn nun ein Graph? Vereinfacht gesagt: Ein Gebilde aus Knoten und Kanten, d.h. Punkten und Linien, die jeweils zwei (nicht notwendigerweise unterschiedliche) Punkte verbinden. Die abstrakte Beschreibung lässt noch nicht viel erahnen, wie ein solche Graph aussieht, weshalb ich auf eine Visualisierung eines Graphen verweisen möchte:

Graph mit sechs Knoten

Hier sieht man, was die Knoten und was die Kanten sind. Das interessante an solchen Darstellungen ist, dass es theoretisch unendlich viele Darstellungen eines Graphs gibt, sodass man den Graphen auch völlig anders hätte anordnen können. Im wesentlichen geht es darum, dass in jeder dieser Darstellungen die gleichen Knoten miteinander verbunden sind. Es gibt in der Informatik sogar eine eigene Disziplin, die sich mit dem Zeichnen von Graphen beschäftigt, das sog. graph drawing.

Da wir nun wissen, wie sich Graphen visualisieren lassen, sollte auch noch geklärt werden, wie sich Graphen definieren lassen. Die allgemeinste Formulierung ist: G = (V,E) ist ein Graph. V entspricht der Menge der Knoten (engl. vertices) und E der Menge der Kanten (engl. edges). D.h. der Graph G besteht aus der Knotenmenge V und der Kantenmenge E. Sei G = (V,E) der Graph, der durch obige Grafik dargestellt ist, so ist V = {1,2,3,4,5,6} und E = {{1,2}, {1,5}, {2,3}, {2,5}, {3,4], {4,5}, {4,6}}. Für jede Kante {x,y} ∈ E gilt, dass x und y durch eine Kante miteinander verbunden sind. Durch die Mengenschreibweise wird klar, dass {x,y} = {y,x} gilt und somit die Reihenfolge der durch die Kanten verbundenen Knoten nicht von Belang ist. Wir sprechen in diesem Fall von einem ungerichteten Graphen.

Ein praxisrelevantes Beispiel für einen ungewichteten Graphen wurde bereits in einem anderen Artikel gegeben:  Six Degrees of Separation (friend of a friend). Dabei stellte jede Person im sozialen Netzwerk einen Knoten dar und eine Kante zwischen zwei Personen existierte genau dann, wenn die beiden Personen befreundet waren. Das zu lösende Problem bestand darin, herauszufinden über wie viele Ecken man einen anderen Benutzer kennt – dabei war natürlich die geringste Anzahl von Ecken gefragt. Graphentheorisch formuliert, lautete das Problem, das sog. kürzester Weg-Problem zu lösen, was im konkreten Fall durch den  Dijkstra-Algorithmus geschah. D.h. man sucht den kürzesten Weg von einem Knoten zu einem anderen Knoten.

Im Gegensatz zu den ungerichteten Graphen gibt es natürlich auch gerichtete Graphen, bei denen die Kanten eine Richtung besitzen. Ein Beispiel hierfür ist der folgende Graph:

Gerichteter Graph

Formal entspricht der obige Graph G = (V, E) mit V = {A,B,C,D,E,F} und E = {(A,B), (B,C), (C,E), (D,B), (E,D), (E,F)}. Für jede gerichtete Kante (x,y) ∈ E gilt, dass eine Kante von x nach y führt. Aus der Tupelschreibweise folgt, dass die Richtung relevant ist, da (x,y) ≠ (y,x) gilt, wenn x ≠ y. Verschiedene Arten von Graphen unterscheiden sich also in der Definition ihrer Kanten.

Da jeder Webentwickler bereits mit Datenbanken gearbeitet haben wird, sollte jedem derselben referentielle Integrität bekannt sein. Das Ziel ist es, in jedem Zustand zu gewährleisten, dass zu jeder Zeile einer Tabelle die referenzierten Zeilen existieren. Verwendet man eine Löschweitergabe (CASCADE DELETE), so soll in jedem Schritt die referentielle Integrität gewährleistet sein. Auch dieses Problem lässt sich auf einen Graphen abstrahieren: Jede Zeile stellt einen Knoten dar und zwischen einer Zeile A und einer Zeile B existiert genau dann eine gerichtete Kante von A nach B, wenn A auf B referenziert. Auf Grundlage eines solchen Graphen lässt sich dann ein Algorithmus, das sog. Topologische Sortieren, anwenden, der eine Löschreihenfolge bestimmt ohne die referentielle Integrität zu gefährden.

Die beiden bisher beschriebenen Arten von Graphen lassen sich noch um den Zusatz gewichtet erweitern. Bei einem gewichteten Graphen existiert eine Gewichtsfunktion f: E → R, die jeder Kante einen (reellen) Wert zuordnet, wie der folgende gewichtete Graph zeigt:

Ungerichteter gewichteter Graph

Das Erkennen der Knoten- bzw. Kantenmenge sollte keine Probleme mehr bereiten, deshalb wird lediglich gezeigt, wie die Gewichtsfunktion f definiert ist:

• f({1,2}) = f({2,1}) = 2
• f({1,4}) = f({4,1}) = 5
• f({2,3}) = f({3,2}) = 14
• f({2,4}) = f({4,2}) = 5
• f({2,5}) = f({5,2}) = 4
• f({3,5}) = f({5,3}) = 34
• f({4,5}) = f({5,4}) = 58

Ein häufiges Einführungsbeispiel sind Straßennetze, die graphentheoretisch modelliert werden können. Jeder Knoten entspricht dabei einer Kreuzung und eine Kante zwischen zwei Kreuzungen existiert genau dann, wenn diese Kreuzungen direkt durch eine Straße miteinander verbunden sind. Um Einbahnstraßen zu berücksichtigen wäre hierbei ein gerichteter Graph zweckmäßig. Außerdem erhält jede Kante ein Gewicht, welche die Länge des Straßenabschnitts angibt. Um den kürzesten Weg zu finden, wie es beispielsweise Routenplaner tun, lässt sich auf diesem Graphen ein Algorithmus zur Bestimmung des kürzesten Pfads auf gewichteten Graphen anwenden, wie z.B. der bereits genannte Dijkstra-Algorithmus oder der besser geeignete A*-Algorithmus.

Da jetzt die grundlegendsten Typen von Graphen geklärt sind, können wir zur Darstellung von Graphen innerhalb eines Programms kommen. Die wahrscheinlich bekannteste Darstellung ist die Adjazenzliste (wörtlich Nachbarschaftsliste), in der jedem Knoten eine Liste von benachbarten Knoten zugeordet wird. In PHP lässt sich dies mithilfe von Arrays sehr einfach lösen. Der gerichtete Graph ließe sich folgendermaßen in PHP-Code denotieren:

$adj = array(
	'A' => array('B'),
	'B' => array('C'),
	'C' => array('E'),
	'D' => array('B'),
	'E' => array('D','F'),
	'F' => array()
);

Über $adj[$x] erhält man die Nachbarn des Knotens $x. Ungerichtete Graphen lassen sich analog definieren: Existiert zwischen x und y eine Kante, so ist y in der Nachbarschaftsliste von x und x ist in der Nachbarschaftsliste von y. Der erste ungerichtete Graph wäre somit folgendermaßen denotiert:

$adj = array(
	1 => array(2,5),
	2 => array(1,3,5),
	3 => array(2,4),
	4 => array(3,5,6),
	5 => array(1,2,4),
	6 => array(4)
);

Eine solche Darstellung eignet sich für viele Algorithmen. Allerdings gibt es eine weitere Darstellung, die vor allem mit der objektorientierten Programmierung assoziiert ist. Das Prinzip ist sehr ähnlich zu dem von Adjazenzlisten, aber der große Unterschied besteht darin, dass jeder Knoten durch ein Objekt repräsentiert wird und jeder Knoten in der Lage ist, seine Nachbarn zurückzugeben. Diese Variante ist vor allem dann nützlich, wenn ein Knoten mehr als nur ein primitiver Wert ist. Folgender PHP-Code, der den gerichteten Graphen darstellt, sollte diese Idee verdeutlichen:

class Node {
	private $identity = null;
	private $neighbours = array();

	public function __construct ($identity) {
		$this->identity = $identity;
	}

	public function connect (Node $node) {
		$this->neighbours[] = $node;
		return $this;
	}

	// Getter & Setter ...
}
$a = new Node('A');
$b = new Node('B');
$c = new Node('C');
$d = new Node('D');
$e = new Node('E');
$f = new Node('F');
$a->connect($b);
$b->connect($c);
$c->connect($e);
$d->connect($b);
$e->connect($d)->connect($f);

Da wir nun computerinterne Darstellungen von Graphen kennen, können wir auf diesen auch Algorithmen ausführen, die allerdings in weiteren Artikeln weitergeführt werden müssen, da der Rahmen keine ausführliche Beschreibung von grundlegenden Algorithmen mehr zulässt. Wer Vorschläge in Richtung bestimmter Themen hat, darf sich natürlich gerne in den Kommentaren äußern.