EntwurfRZ

Wiki-Quelltext dieser Seite.

<language>Java</language>
=Relevanz und Motivation=

==Entstehung von Theorien und Modellen==
* Meist aus einem praktischen Problem heraus
* Zusammentragen aller Fakten die damit irgendwie zu tun haben
* Weglassen aller Dinge die keinen direkten Einfluss haben
* Verallgemeinerung / Abstraktion
* Finden von Ähnlichkeiten mit bekannten einfacheren Dingen
* Entwurf eines Modells mit diesen einfacheren Dingen
* Verhältnismäßig einfache Bestimmung von übertragbaren Eigenschaften und Konsequenzen

==Leonard Euler 1737==
* Problem der Königsberger Brücken
* Weglassen von Entfernungen und Ausmaßen
* Einfluss haben nur Stadtteile und Brücken
* Abstraktion zu Punkten mit Verbindungslinien
* Lösung des Problems mit Punkten und Verbindungen löst auch das Problem mit Stadtteilen und Brücken
* Entstehung des Graphenmodells

==Die Graphentheorie als Modell==
* Sehr minimalistisch, nur Punkte mit Verbindungen
* Dadurch übertragbar auf alle Arten von Beziehungen zwischen Objekten 
** Städte und Zugverbindungen
** Freundschaften zwischen Menschen
** Verlinkung von Internetseiten
* Viele praktische Probleme lassen sich zu einem Graphenproblem umformulieren
** Ausfallwahrscheinlichkeit von Netzwerken
** Routenermittlung bei der Navigation
** Einstufung der Wichtigkeit von Einzelnen in einer Gruppe
* Graphentheorie stellt bereits Lösungen zur Verfügung
* Meist ist "nur noch" eine Interpretation erforderlich

==Arbeiten mit dem Graphenmodell==
* Mathematik des Modells ist gut dokumentiert
* Kritisch sind die Transformationen
** Formulierung eines praktischen Problems im Graphenmodell
** Interpretation des mathematischen Ergebnisse für die Praxis
* Falsche Formulierung oder falsche Interpretation liefert keine Problemlösung
* Zeitverteilung eines Softwareentwicklers: 10% tippen, 90% denken
* Gute Programmierer denken immer abstrakt (also in Modellen)
* Wenn man viele Modelle kennt, muss man sich selbst keine ausdenken
* Die Einfachheit der Graphentheorie macht sie zu einem Universalmodell

=Knoten und Kanten=
;Definition Graph
:$G=(V,E),~V=\{v\},~V \neq \emptyset,~E=\{(x,y)~|~x, y \in V\}$

<popup name="Ausführliche Definition">
;Definition Graph
:$\color{red}G=\color{blue}(V,E\color{blue}),~V=\color{green}\{v\color{green}\},~V \color{orange}{\neq \emptyset},~E=\color{green}\{\color{blue}(x,y\color{blue})~\color{magenta}|~x,y \in V\color{green}\}$
<br/>
:'''Gelesen:''' Ein $\color{red}{Graph}$ ist ein $\color{blue}{geordnetes~Paar}$, wobei dessen erstes Element eine $\color{green}{Menge}$ ist, welche $\color{orange}{nicht~leer}$ sein darf, und dessen zweites Element eine $\color{green}{Menge}$ von $\color{blue}{geordneten~Paaren}$ ist, $\color{magenta}{mit~der~Eigenschaft,~dass}$ die Paarelemente in der ersten Menge enthalten sein müssen.
<br/>
:'''Also:''' Ein Graph ist eine gewisse Anzahl von Objekten die untereinander Paare bilden können.
</popup>
* $V$ (für ''Vertices'') ist die Menge der Knoten
* $E$ (für ''Edges'') ist die Menge der Kanten
* '''Man beachte:''' Es ist nicht festgelegt, was $v$ eigentlich ist!

==Was ist ein Graph?==
Zur grafischen Darstellung bieten sich Punkte und Linien an:<br/>
[[Bild:RaZ_Graphen.png|800px]]
<popup name="Lösung">Alle außer a), b) und c)</popup>

==Konsequenzen==
* Ein Graph muss mindestens einen Knoten enthalten
* Ein Graph muss nicht unbedingt Kanten haben
* Eine Kante muss immer durch 2 (nicht zwingend verschiedene) Knoten begrenzt sein
* Ein Knotenpaar kann durch mehrere Kanten verbunden sein
* Zwei Graphen sind gleich, wenn sie die gleichen Knoten enthalten, die durch die gleichen Kanten verbunden sind
* Adjazenz = Nachbarschaft = Es gibt etwas trennendes dazwischen
** Nur zwischen Knoten und Knoten bzw. zwischen Kante und Kante
** Dazwischen ist immer eine Kante oder ein Knoten
* Inzidenz = Angrenzung = Es gibt direkten Kontakt
** Nur zwischen Knoten und Kante
* $n$ für Anzahl der Knoten
* $m$ für Anzahl der Kanten

==In der Praxis==
* Knoten und Kanten werden immer als Objekte mit Beziehungen interpretiert
* Dadurch werden die Konsequenzen intuitiv klar
* Erst wenn es ein Objekt gibt, kann man etwas darüber aussagen: "ist allein"
* Zwei Objekte ohne Verbindung sind auch sinnvoll: "nicht allein, aber isoliert"
* Eine Beziehung findet per Definition immer zwischen Objekt'''en''' statt
* Objekte müssen dabei nicht zwingend verschieden sein (z.B. Besitzer$\leftrightarrow$Eigentümer)

==Modellierung==
* Transformation einer Gegebenheit/eines Problems ins Graphenmodell
* Scheinbar offensichtlich (Computernetzwerke, Straßen, Facebook-Freundschaften)
* In der Praxis: Immer abhängig von der Problemstellung!
* z.B. Kabelverlegung in einem Haus
** Wie verlegt man die Kabel, sodass die verwendete Gesamtkabellänge minimal ist?
** Wie teile ich eine 50m Kabelrolle auf, sodass der Verschnitt möglichst gering ist?
* Kein Patentrezept um von der konkreten Problemstellung zum abstrakten Graphenmodell zu gelangen
* Hilfreiche Fragen die man sich stellen kann
** Welches Ergebnis wird gebraucht?
** Welches Ergebnis der Graphentheorie soll genutzt werden?
* Oft helfen Zwischen-Abstraktionen anstatt direkt zu Knoten und Kanten zu abstrahieren
** Zustände und deren Übergänge
** Situationen und deren Änderung
* Grafische Darstellung von Graphen kann geometrische Körper ergeben

=Programmiertechnische Verarbeitung=
* Wie bilde ich das gestellte Problem programmtechnisch ab?
*# Mathematische Analyse ($\rightarrow$ mathematische Grundalgorithmus)
*# Verbesserung des Algorithmus (dynamic programming, divide & conquer, ...)
*# Definition der Datenstruktur zur effizienten Unterstützung des Algorithmus
* Wahl der Datenstruktur immer nach Anforderungen des Algorithmus
** Soll der Graph variabel sein? (Array vs. Hashset)
** Gibt es isolierte Knoten? (Redundanz erforderlich)
** Welche Operationen sollen durchgeführt werden? (Zugriff, Suche, Manipulation)
* Speicherbedarf vs. Effizienz

==Naive Herangehensweise==
* Streng nach Definition: Menge von Knoten + Menge von Kanten (zwischen Knoten)<br/><code id="562384e909645">
class Graph{
	int[] vertices;
	Edge[] edges;
}
class Edge{
	int from;
	int to;
}
</code>
* Kante von a nach b vorhanden? $\mathcal{O}(m)$
* Anzahl anliegender Kanten am Knoten? $\mathcal{O}(m)$
* Speicherbedarf $\mathcal{O}(n+2m)$

==Adjazenzmatrix==
* Matrix der Größe $n\times n$, 0 oder 1 für jedes Punkte-Paar<br/>[[Bild:RaZ_GraphMatrix.png|500px]][[Bild:RaZ_AdjazenzMatrix.png|300px]]
* Kante von a nach b vorhanden? $\mathcal{O}(1)$
* Anzahl anliegender Kanten am Knoten? $\mathcal{O}(n)$
* Speicherbedarf $\mathcal{O}(n^2)$ (oder doch etwas weniger möglich?)
* Codebeispiel:<br/><code id="5626b165b8dff">
class Graph<T>{
	T[][] adjacency;
}
</code>
* Speicherbedarf unabhängig von der Kantenanzahl
* Bei großen Graphen nicht mehr möglich

==Adjazenzliste==
* Weglassen der Nullen in der Adjazenzmatrix
* Liste der Knoten mit deren Nachbarn<br/>[[Bild:RaZ_GraphMatrix.png|500px]][[Bild:RaZ_Adjazenzliste.png|380px]]
* Kante von a nach b vorhanden? $\mathcal{O}(n)$
* Anzahl anliegender Kanten am Knoten? $\mathcal{O}(1)$
* Speicherbedarf $\mathcal{O}(n+m)$
* Codebeispiel:<br/><code id="5626b165b8ea9">
class Graph<T>{
	int[] neighborIndex;
	T[] neighbors;
}
</code>
** Für jeden Knoten ein <tt>neighborIndex</tt> wo in <tt>neighbors</tt> seine adjazenten Knoten abgelegt sind<br/>!!!!!!Bild der Felder mit Pfeilen
** Knoten ohne Nachbar erkennbar wenn der Folgeknoten den gleichen <tt>neigborIndex</tt> hat<br/>Achtung! Sonderbehandlung des letzten Knotens
* weniger Speicherbedarf als Adjazenzmatrix wenn Graph nicht vollständig

==Kantenliste==
* Nur die Kanten (zwischen 2 Knoten) werden gehalten<br/>[[Bild:RaZ_GraphMatrix.png|500px]][[Bild:RaZ_Kantenliste.png|380px]]
* Kante von a nach b vorhanden? $\mathcal{O}(m)$
* Anzahl anliegender Kanten am Knoten? $\mathcal{O}(m)$
* Speicherbedarf $\mathcal{O}(m)$
* Codebeispiel:<br/><code id="5626b165b8f32">
class Graph<T>{
	T[][] edges; // second dimension is 2
}
</code>
* Speicherbedarf unabhängig von der Knotenanzahl
* keine Unterstützung isolierter Knoten

==In der Praxis==
* Knoten und Kanten sind meist komplexere Datenstrukturen (beliebige Klassen)
* Bei Algorithmenimplementation ''generics'' bzw. ''templates'' benutzen
* Hilfsdatenstrukturen '''richtig''' verwenden (HashMap, HashSet)
* Redundanz vermeiden (Speicherbedarf minimieren), oder auch explizit nutzen (Effizienzsteigerung)

=Grad eines Knotens=
;Definition
:$d(v)=|\{(v,x)~|~(v,x) \in E\}| + |\{(y,v)~|~(y,v) \in E\}|$

<popup name="Ausführliche Definition">
;Definition
:$\color{red}d(\color{orange}v)=\color{brown}|\color{green}\{\color{blue}(\color{orange}v,x\color{blue})~\color{magenta}{|~(v,x) \in E}\color{green}\}\color{brown}|~\color{black}+~\color{brown}|\color{green}\{\color{blue}(y,\color{orange}v\color{blue})~\color{magenta}{|~(y,v) \in E}\color{green}\}\color{brown}|$
<br/>
:'''Gelesen:''' Der $\color{red}{Grad}$ eines $\color{orange}{Knotens}$ ist die $\color{black}{Summe}$ der $\color{brown}{Kardinalitäten}$ der $\color{green}{Mengen}$ von $\color{blue}{geordneten~Paaren}$, $\color{magenta}{welche~in~E~enthalten~sein~müssen}$, die diesen $\color{orange}{Knoten}$ als erstes oder zweites Paarelement haben.
<br/>
:'''Also:''' Die Anzahl der Kanten die an einem Knoten anliegen.
</popup>
[[Bild:RaZ_Degree.png:500px]]
* Einzelner Knoten ohne anliegende Kanten hat Grad 0 (isolierter Knoten)
* Schleife an einem Knoten erhöht den Grad um 2
* Haben alle Knoten den gleichen Grad ist der Graph regulär<br/>genauer: bei Grad k $\rightarrow$ k-regulär
* Stark regulär:
** 2 benachbarte Knoten haben immer gleich viele gleiche Nachbarknoten und
** 2 '''nicht''' benachbarte Knoten haben immer gleich viele gleiche Nachbarknoten
* Ein Graph hat: Minimalgrad, Maximalgrad, Durchschnittsgrad
* Wichtig: $\sum_{i=1}^n d(v_i)=2\cdot m$
** Summe aller Grade entspricht doppelter Kantenanzahl im Graph
** Da jede Kante den Grad ihrer 2 angrenzenden Knoten um 1 erhöht
* Daraus folgt: Anzahl der Knoten mit ungeradem Grad muss gerade sein
<popup name="Beweis">
# Summe aller Grade ist $\color{blue}{gerade}$ wegen $\textbf{2}\cdot m$
# Summe aller $\color{blue}{geraden}$ Grade ist auch $\color{blue}{gerade}$
# Wegen 1. muss die Summe aller $\color{red}{ungeraden}$ Grade auch $\color{blue}{gerade}$ sein
# Wegen 3. muss die Anzahl der Knoten mit $\color{red}{ungeradem}$ Grad $\color{blue}{gerade}$ sein
</popup>
* Praktisch: schnelle Überprüfbarkeit einer Aussage<br/>Unter 7 Unternehmen unterhält jedes Geschäftsbeziehungen zu genau 3 anderen Unternehmen. Möglich?

=Isomorphie=
* Gleichstrukturiertheit von Graphen $G \sim G'$
* Grafische Darstellung der Graphen kann ineinander überführt werden (Morphing)
* Achtung: Isomorphie $<>$ Gleichheit
** Knotennamen für Isomorphie irrelevant
** Ebenso Kantenbewertungen
** Aber: Kantenrichtungen dürfen nicht ignoriert werden
*Algorithmische Prüfung auf Isomorphie <span style="font-size:88%">''($\mathcal{O}$ per Adjazenzmatrix)''</span>
** Anzahl der Knoten muss gleich sein $=\mathcal{O}(1)$
** Anzahl der Kanten bzw. Summe der Grade muss gleich sein $=\mathcal{O}(n^2)$
* Das reicht aber noch nicht!  !!!!!!!!Bild zweier nicht-isomorper Graphen mit gleichen Inv.!!!!!!
** Die Adjazenzmatrix muss gleich sein von mindestens einer ihrer '''Permutationen''' $=\mathcal{O}(n!)$
** Optimierung lt. Ullmann: Partitionieren! (Gruppierung von Knoten mit gleichem Grad)<br/>Dadurch statt $9!=362.880$ Möglichkeiten, Einschränkung auf z.B. $2!\cdot 7!=10.080$ Möglichkeiten
** Hier gibts einen Ferrari zu holen...