Make introduction longer

DokumentationAufgabe1.tex

@@ -26,6 +26,7 @@
 \usepackage{graphicx,subcaption,float}
 % Für Skizzen
 \usepackage{tkz-euclide}
+\usepackage{tkz-graph}
 \usetkzobj{all}
 
 % Für Quelltext
@@ -66,7 +67,58 @@
 \tableofcontents
 
 \section{Lösungsidee}
-Lisas Haus und die Ecken der Hindernisse kann man als Graph darstellen. Eine Kante zwischen zwei Ecken ist nur dann vorhanden, wenn Lisa direkt vom einen zum anderen Punkt laufen kann. Mögliche Wege, die nicht geradlinig sind, sind immer suboptimal, da diese immer einem Hindernis ausweichen würden. Stattdessen wäre es besser, zuerst zu diesem Hindernis zu gehen und dann weiterzugehen. Die Gewichtung der Kanten kann nicht einfach nur der euklidische Abstand der beiden Punkte sein, da Lisa nicht den kürzesten Weg finden will, sondern möglichst lange schlafen will. Daher haben diese ein Gewicht, das der Zeit entspricht, die Lisa früher aufstehen müsste, wenn sie zu einem bestimmten Punkt geht, statt direkt zum Bus zu gehen. Es gibt viele Suchalgorithmen für Graphen, die einen kürzesten Weg bestimmen. Allerdings ist es nicht einfach, eine Heuristik, die z.B. von A* benötigt wird, aufzustellen. Sowohl die Distanz zur y-Achse auch als die Anzahl der Hindernisse auf direktem Weg zum Bus können nicht in das Einheitensystem der Kantengewichte übertragen werden. Daher sind Suchalgorithmen ohne solche Heuristikfunktionen besser geeignet. Eine Breiten- oder Tiefensuche wäre allerdings nicht besonders performant, da diese entweder zu langsam vorwärtskommen (Breitensuche) oder sich zuerst auf eine suboptimal Route fokussieren können (Tiefensuche). Da die Kantengewichte immer nicht-negativ sind, kann auch der Dijkstra-Algorithmus verwendet werden. Wenn Lisa am Ende der Route zum Bus läuft, gibt es keinen, einen oder zwei Treffpunkte, bei denen Lisa (ohne zu warten) den Bus erwischt (siehe Abb. \ref{fig:treffpunkte}).
+Lisas Haus und die Ecken der Hindernisse kann man als Graph darstellen (siehe Abb. \ref{fig:graph}). Eine Kante zwischen zwei Ecken ist nur dann vorhanden, wenn Lisa direkt vom einen zum anderen Punkt laufen kann. Mögliche Wege, die nicht geradlinig sind, sind immer suboptimal, da diese immer einem Hindernis ausweichen würden. Stattdessen wäre es besser, zuerst zu diesem Hindernis zu gehen und dann weiterzugehen. Die Gewichtung der Kanten kann nicht einfach nur der euklidische Abstand der beiden Punkte sein, da Lisa nicht den kürzesten Weg finden will, sondern möglichst lange schlafen will. Daher haben diese ein Gewicht, das der Zeit entspricht, die Lisa früher aufstehen müsste, wenn sie zu einem bestimmten Punkt geht, statt direkt zum Bus zu gehen. Es gibt viele Suchalgorithmen für Graphen, die einen kürzesten Weg bestimmen. Allerdings ist es nicht einfach, eine Heuristik, die z.B. von A* benötigt wird, aufzustellen. Sowohl die Distanz zur y-Achse auch als die Anzahl der Hindernisse auf direktem Weg zum Bus können nicht in das Einheitensystem der Kantengewichte übertragen werden. Daher sind Suchalgorithmen ohne solche Heuristikfunktionen besser geeignet. Eine Breiten- oder Tiefensuche wäre allerdings nicht besonders performant, da diese entweder zu langsam vorwärtskommen (Breitensuche) oder sich zuerst auf eine suboptimal Route fokussieren können (Tiefensuche). Da die Kantengewichte immer nicht-negativ sind, kann auch der Dijkstra-Algorithmus verwendet werden. Wenn Lisa am Ende der Route zum Bus läuft, gibt es keinen, einen oder zwei Treffpunkte, bei denen Lisa (ohne zu warten) den Bus erwischt (siehe Abb. \ref{fig:treffpunkte}).
+
+Ein weiteres Problem ist die Bestimmung der Kanten. Um sicher alle möglichen Wege zu finden, müssen $\frac{n*(n-1)}{2}+n$ Überprüfungen durchgeführt werden, wobei $n$ die Anzahl der Wegpunkte ist. Wegpunkte sind Lisas Haus und die Ecken der Hindernisse. Da die Anzahl der benötigten Überprüfungen ca. quadratisch anwächst, sollten diese möglichst schnell durchgeführt werden. Um für jeden Wegabschnitt zu überprüfen, ob er eins der Hindernisse schneidet (nicht nur berührt), kann man für jedes Hindernis ausrechnen, ob die Gerade das entsprechende Polygon schneidet. Allerdings würde die Rechenzeit dann kubisch wachsen.
+
+Zudem ist die Anzahl der möglichen Routen sehr groß: ca. $n!$. In einem Suchalgorithmus sollten also zuerst die Routen ausprobiert werden, die wahrscheinlich zu einer guten Lösung führen. Unvollständige Routen, die schlechter als während der Suche gefundene Lösungen sind, können auch verworfen werden.
+
+\begin{figure}[H]
+\centering
+\begin{subfigure}{.48\textwidth}
+	\centering
+	\begin{tikzpicture}
+		\tkzInit[xmax=5,ymax=2.5]
+		\tkzAxeXY
+		\tkzGrid
+		\tkzDefPoints{0.75/0.75/P0_0,2.25/0.75/P0_1,1.75/2/P0_2,1.25/2/P0_3}
+		\tkzDrawPolygon[fill=black,line width=1pt,opacity=0.5](P0_0,P0_1,P0_2,P0_3)
+		\tkzDefPoint(3,1){R0}
+		\tkzDrawPoint[fill=red,color=black,size=13](R0)
+	\end{tikzpicture}
+	\caption{Eingabe}
+	\label{abb:eingabe}
+\end{subfigure}%
+\begin{subfigure}{.48\textwidth}
+	\centering
+	\begin{tikzpicture}
+		\SetGraphUnit{1.5}
+		\GraphInit[vstyle=Normal]
+		\SetVertexSimple[Shape=circle,FillColor=green!50]
+		\Vertex{L}
+		\SetVertexSimple[Shape=rectangle,FillColor=blue!50]
+		\WE(L){P0E0}
+		\WE(P0E0){P0E1}
+		\NO(P0E1){P0E2}
+		\EA(P0E2){P0E3}
+		\SetVertexSimple[Shape=circle,FillColor=yellow!50]
+		\NOWE(P0E2){B}
+		\Edge(L)(P0E0)
+		\Edge(L)(P0E3)
+		\Edge(P0E0)(P0E1)
+		\Edge(P0E0)(P0E3)
+		\Edge(P0E1)(P0E2)
+		\Edge(P0E2)(P0E3)
+		\Edge(P0E1)(B)
+		\Edge(P0E2)(B)
+		\Edge(P0E3)(B)
+	\end{tikzpicture}
+	\caption{Graph}
+	\label{abb:graph-eingabe}
+\end{subfigure}
+\caption{Konvertierung der Eingabe zu einem Graphen}
+\label{fig:graph}
+\end{figure}
 
 \begin{figure}[H]
 \centering