Minor docs update
This commit is contained in:
parent
4cb06640bc
commit
f4a7dbc19e
@ -251,7 +251,7 @@ Lisas Haus und die Ecken der Hindernisse kann man als Graph darstellen (siehe Ab
|
|||||||
\label{fig:gewicht}
|
\label{fig:gewicht}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
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 suboptimale Route fokussieren können (Tiefensuche). Da die Kantengewichte immer nicht-negativ sind, kann auch der Dijkstra-Algorithmus verwendet werden.
|
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, was von A* benötigt wird. 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 suboptimale Route fokussieren können (Tiefensuche). Da die Kantengewichte immer nicht-negativ sind, kann auch der Dijkstra-Algorithmus verwendet werden.
|
||||||
|
|
||||||
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.
|
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.
|
||||||
|
|
||||||
@ -315,7 +315,7 @@ Das Programm benutzt den Dijkstra-Algorithmus, um die beste Route für Lisa zu f
|
|||||||
Der Weg von Lisa und dem Bus wird im SVG-Dokument animiert angezeigt. Zusätzlich zu den unbedingt benötigten Ausgaben wie z.B. der Start- und Zielzeit gibt das Programm auch noch die theoretisch (ohne Hindernisse) beste Startzeit aus. Nützlich sind auch die Debug-Ausgaben, die Statistiken zur Eingabedatei und der Performanz (Zeit pro Iteration, Gesamtzeit) enthalten.
|
Der Weg von Lisa und dem Bus wird im SVG-Dokument animiert angezeigt. Zusätzlich zu den unbedingt benötigten Ausgaben wie z.B. der Start- und Zielzeit gibt das Programm auch noch die theoretisch (ohne Hindernisse) beste Startzeit aus. Nützlich sind auch die Debug-Ausgaben, die Statistiken zur Eingabedatei und der Performanz (Zeit pro Iteration, Gesamtzeit) enthalten.
|
||||||
|
|
||||||
\subsection{Laufzeitanalyse}
|
\subsection{Laufzeitanalyse}
|
||||||
Da programmintern der Dijkstra-Algorithmus verwendet wird, entspricht die Laufzeit in etwa diesem. Somit ist die Zeitkomplexität ca. $O(n^2)$, wobei $n$ die Anzahl der Ecken aller Polygone ist. Effektiv können allerdings in jedem Schritt nur eine kleine Anzahl anderer Ecken erreicht werden, was den Algorithmus beschleunigen könnte. In Abschnitt \ref{performance} werden diese theoretischen Werte überprüft.
|
Da programmintern der Dijkstra-Algorithmus verwendet wird, entspricht die Laufzeit in etwa diesem. Somit ist die Zeitkomplexität ca. $O(n^2)$, wobei $n$ die Anzahl der Ecken aller Polygone ist. Effektiv können allerdings in jedem Schritt nur eine kleine Anzahl anderer Ecken erreicht werden, was den Algorithmus beschleunigen könnte. Allerdings müssen auch die Kanten bestimmt werden, was im schlechtesten Fall $O(n^3)$ Rechenzeit beanspruchen kann. In Abschnitt \ref{performance} werden diese theoretischen Werte überprüft.
|
||||||
|
|
||||||
\subsection{Optimierungen}
|
\subsection{Optimierungen}
|
||||||
Das Programm benutzt bestimmte Heuristiken, um die Suche zu beschleunigen. Eine davon ist die maximal mögliche Aufstehzeit für eine bestimmte Route. Um diese schnell zu berechnen, kann man zunächst feststellen, das der Bus mit konstanter Geschwindigkeit fährt. Deshalb ist eine Startposition des Busses mit einer kleineren y-Koordinate äquivalent zu einem früheren Aufstehen von Lisa. Das Programm berechnet daher die höchstmögliche Startposition für eine gegebene Route, weil diese Größe proportional zur gesuchten Größe ist.
|
Das Programm benutzt bestimmte Heuristiken, um die Suche zu beschleunigen. Eine davon ist die maximal mögliche Aufstehzeit für eine bestimmte Route. Um diese schnell zu berechnen, kann man zunächst feststellen, das der Bus mit konstanter Geschwindigkeit fährt. Deshalb ist eine Startposition des Busses mit einer kleineren y-Koordinate äquivalent zu einem früheren Aufstehen von Lisa. Das Programm berechnet daher die höchstmögliche Startposition für eine gegebene Route, weil diese Größe proportional zur gesuchten Größe ist.
|
||||||
|
Loading…
Reference in New Issue
Block a user