mirror of
https://github.com/2martens/uni.git
synced 2026-05-07 11:56:26 +02:00
Compare commits
16 Commits
opti_blatt
...
opti_blatt
| Author | SHA1 | Date | |
|---|---|---|---|
| 4211ad6c4d | |||
| 9db6bbb2eb | |||
| 3162e632f7 | |||
| 8823050a6f | |||
| 9ecd5f7110 | |||
| 99da603ffe | |||
| ad55ee1a2b | |||
| ebd1d8c61f | |||
| b0400eb4f0 | |||
| 5ffb5b5e2b | |||
| 0d6a5bd77b | |||
| 3c69d2443e | |||
| 307a188688 | |||
| ffdf909298 | |||
| 72d3ced337 | |||
| a6f03dd921 |
1
.gitignore
vendored
1
.gitignore
vendored
@ -33,3 +33,4 @@
|
||||
*.xdy
|
||||
*.tdo
|
||||
*.zip
|
||||
*~
|
||||
|
||||
@ -5,12 +5,15 @@
|
||||
\usepackage{amsmath}
|
||||
\usepackage{amsfonts}
|
||||
\usepackage{amssymb}
|
||||
\usepackage{bytefield}
|
||||
\usepackage{paralist}
|
||||
\usepackage{gauss}
|
||||
\usepackage{pgfplots}
|
||||
\usepackage{textcomp}
|
||||
\usepackage[locale=DE,exponent-product=\cdot,detect-all]{siunitx}
|
||||
\usepackage{tikz}
|
||||
\usepackage{algorithm}
|
||||
\usepackage{algorithmic}
|
||||
\usetikzlibrary{matrix,fadings,calc,positioning,decorations.pathreplacing,arrows,decorations.markings}
|
||||
\usepackage{polynom}
|
||||
\polyset{style=C, div=:,vars=x}
|
||||
@ -25,9 +28,12 @@
|
||||
\let\@ifnextchar\new@ifnextchar
|
||||
\array{#1}}
|
||||
\makeatother
|
||||
\parskip 12pt plus 1pt minus 1pt
|
||||
\parindent 0pt
|
||||
|
||||
\begin{document}
|
||||
\author{Tronje Krabbe, Jim Martens (6420323)}
|
||||
\author{Reinhard Köhler (6425886?), Tronje Krabbe (6435002), \\
|
||||
Jim Martens (6420323)}
|
||||
\title{Hausaufgaben zum 6. November}
|
||||
\subtitle{Gruppe 8}
|
||||
\maketitle
|
||||
@ -37,22 +43,53 @@
|
||||
\subsection{} %b
|
||||
Ein voller Baum der Tiefe $l$ hat auf der untersten Ebene $k^{l}$ Knoten. Daraus ergibt sich diese Summe:
|
||||
\[
|
||||
\sum\limits_{i=0}^{l} k^{i}
|
||||
\sum\limits_{i=0}^{l} k^{i} = k^{l+1} - 1
|
||||
\]
|
||||
Dies gilt da in einem vollen Baum die Anzahl Knoten in einer Ebene immer einer Potenz von $k$ entsprechen.
|
||||
\subsection{} %c
|
||||
Ein vollständiger Baum der Tiefe $l$ gleicht bis auf die letzte Ebene einem vollen Baum. In der letzten Ebene $l$ kommen maximal $k^{l} - 1$ Knoten vor, damit es ein vollständiger Baum, aber kein voller Baum ist. Daraus ergibt sich diese leicht abgewandelte Formel:
|
||||
\[
|
||||
\sum\limits_{i=0}^{l-1} \left(k^{i}\right) + c : 1 \leq c < k^{l}
|
||||
\]
|
||||
\begin{alignat*}{2}
|
||||
\sum\limits_{i=0}^{l-1} \left(k^{i}\right) + c &:& 1 \leq c < k^{l}
|
||||
\end{alignat*}
|
||||
\subsection{} %d
|
||||
Jeder Knoten hat genau ein Elternknoten mit dem er über eine Kante verbunden ist. Einzige Ausnahme ist der Wurzelknoten, der kein Elternelement hat und damit auch keine Kante, die mit einem solchen verbunden sein könnte. Daher gibt es genau $n-1$ Kanten.
|
||||
\section{} %2
|
||||
\subsection{} %a
|
||||
Laufzeit von Order1:
|
||||
\[
|
||||
T(n) = 2T\left(\frac{n}{2}\right) + n^{0}
|
||||
\]
|
||||
|
||||
Laufzeit von Order2:
|
||||
\[
|
||||
T(n) = 2T\left(\frac{n}{2}\right) + n^{0}
|
||||
\]
|
||||
|
||||
Laufzeit von Order3:
|
||||
\[
|
||||
T(n) = 2T\left(\frac{n}{2}\right) + n^{0}
|
||||
\]
|
||||
\subsection{} %b
|
||||
Die Laufzeiten von Order1, Order2 und Order3 können im best-case auf $1$ verbessert werden.
|
||||
\subsection{} %c
|
||||
Order1: NAOEIFMRLUSGARTH \\
|
||||
Order2: IEOFARMLNGSAUTRH \\
|
||||
Order3: IEFORLMAGASTHRUN
|
||||
\subsection{} %d
|
||||
T = \begin{bytefield}{10}
|
||||
\bitbox{1}{T}
|
||||
\bitbox{1}{E}
|
||||
\bitbox{1}{E}
|
||||
\bitbox{1}{O}
|
||||
\bitbox{1}{Y}
|
||||
\bitbox{1}{R}
|
||||
\bitbox{1}{E}
|
||||
\bitbox{1}{L}
|
||||
\bitbox{1}{V}
|
||||
\bitbox{1}{L}
|
||||
\end{bytefield}
|
||||
\subsection{} %e
|
||||
ALGORITHMSAREFUN
|
||||
\section{} %3
|
||||
\subsection{} %a
|
||||
\begin{alignat*}{2}
|
||||
@ -71,10 +108,31 @@
|
||||
\end{alignat*}
|
||||
Das Ergebnis der letzten Gleichung ist somit das Minima von $f$. Als weitere Absicherung kann das asymptotische Wachstum betrachtet werden. Für einen kleineren Wert als $e$, ist $\ln(x)$ kleiner als $1$. Das Teilen von $x$ durch diesen Wert geringer als $1$ sorgt dafür, dass das Ergebnis größer als $x$ ist. Lässt man $x$ gegen $1$ laufen, läuft der Bruch gegen unendlich. Auf der anderen Seite kann man $x$ gegen unendlich gehen lassen, dann läuft der Bruch auch gegen unendlich, da eine lineare Funktion schneller wächst, als eine logarithmische. Der konstante Faktor am Ende kann dabei außer Acht gelassen werden.
|
||||
\subsection{} %b
|
||||
Die beste Wahl für $k^{*}$ ist $3$. Es werden im worst-case bei der Heap-Größe $n=10^{l}$ mit $l \in \{1,...,9\}$ diese Anzahl an Schritten benötigt.
|
||||
|
||||
\begin{tabular}{c|c|c}
|
||||
$l$ & $k = 3$ & $k = 2$ \\
|
||||
\hline
|
||||
1 & 7 & 7 \\
|
||||
2 & 13 & 14 \\
|
||||
3 & 19 & 20 \\
|
||||
4 & 26 & 27 \\
|
||||
5 & 32 & 34 \\
|
||||
6 & 38 & 40 \\
|
||||
7 & 45 & 47 \\
|
||||
8 & 51 & 54 \\
|
||||
9 & 57 & 60
|
||||
\end{tabular}
|
||||
\subsection{} %c
|
||||
Ein binärer Heap (dementsprechend $k=2$) ist deutlich übersichtlicher als ein ternärer Heap. Außerdem ist ein binärer Heap leichter zu be- bzw. verarbeiten und der Unterschied des Laufzeitaufwandes zwischen einem binären und einem ternären Heap ist nicht sonderlich groß.
|
||||
\subsection{} %d
|
||||
Pro Vertauschen werden $k+1$ Schritte benötigt. Ein Schritt wird benötigt, um das Maximum herauszufinden und $k$ Schritte, um den Max-Heap des aktuellen Knoten nach dem Vertauschen wieder zu einem solchen zu machen. Damit werden zwar viele Schritte zum Finden eines Maximums der Kinder eingespart, allerdings an anderer Stelle wieder durch das Aufrufen von Heapify auf den zusätzlichen Max-Heap ausgegeben. Im Endeffekt ergibt sich damit eine Gesamtlaufzeit von $\lceil (k+1)\log_{k}(n) \rceil$.
|
||||
\subsection{} %e
|
||||
Anwenden von \textsc{Decrease}$(9 \mapsto 1)$ auf Ergebnis von 3d: 2 Vertauschungen \\
|
||||
Anwenden von \textsc{Decrease}$(9 \mapsto 1)$ auf Ergebnis von 3f: eine Vertauschung
|
||||
\subsection{} %f
|
||||
Ein ternärer Heap hat bei gleicher Anzahl an Knoten maximal gleich viele Level, wodurch dieselbe \textsc{Decrease}-Operation bei einem ternären Heap immer maximal gleich viele Vertauschungen wie bei einem binären Heap erfordert.
|
||||
|
||||
\section{} %4
|
||||
\subsection{} %a
|
||||
merge (2 2 5 7 9, 1 2 4 8) \\
|
||||
@ -138,5 +196,31 @@
|
||||
Eine andere Möglichkeit ist das Vertauschen der Fälle in der \texttt{if}-Abfrage. Dabei bleibt die Bedingung der Abfrage gleich, allerdings wird statt dem ersten Element von $x$ das erste Element von $y$ genommen. Im \texttt{else}-Fall wird dann dementsprechend das erste Element von $x$ genommen.
|
||||
\section{} %5
|
||||
\subsection{} %a
|
||||
Man benutzt einen Stack als Zwischenspeicher und einen Stack als die eigentliche Queue. Soll ein Element in die Queue eingefügt werden, wird jedes Element des Hauptstacks nach und nach entfernt und auf den Speicherstack geschrieben. Dann wird das hinzuzufügende Element in den Hauptstack geschrieben. Danach werden nach und nach alle Elemente aus dem Speicherstack entfernt und auf den Hauptstack geschrieben. So sind in dem Hauptstack die Elemente in der Reihenfolge gespeichert, in der sie ausgelesen werden sollen (FIFO-Prinzip). Soll nun ein Element aus der Queue entfernt werden, wird einfach die pop-Operation an dem Hauptstack aufgerufen, womit das Element, das zuerst eingefügt wurde, entfernt wird, wie es bei einer Queue der Fall ist.
|
||||
|
||||
\begin{verbatim}
|
||||
function ENQUEUE(e):
|
||||
if Hauptstack.isEmpty():
|
||||
Hauptstack.push(e);
|
||||
else:
|
||||
for element in Hauptstack:
|
||||
Speicherstack.push(element);
|
||||
Hauptstack.pop();
|
||||
end for
|
||||
Hauptstack.push(e);
|
||||
for element in Speicherstack:
|
||||
Hauptstack.push(element);
|
||||
Speicherstack.pop();
|
||||
end for
|
||||
end if
|
||||
end function
|
||||
|
||||
function DEQUEUE():
|
||||
Hauptstack.pop();
|
||||
end function
|
||||
\end{verbatim}
|
||||
|
||||
Im worst-case ist die Laufzeit von \textsc{Dequeue} $\theta(1)$. Die worst-case Laufzeit von \textsc{Enqueue} ist bei $k$ Elementen $2k+1$.
|
||||
\subsection{} %b
|
||||
Die worst-case Laufzeit von $n$ \textsc{Enqueue}-Operationen beträgt $n \cdot (2n+1) = 2n^{2} + n$. Die amortisierte Laufzeit beträgt dann $\frac{n(2n+1)}{n} = 2n+1$. Dabei muss beachtet werden, dass bei weniger \textsc{Enqueue}- und mehr \textsc{Dequeue}-Operationen dementsprechend auch das Ergebnis weniger groß ausfällt.
|
||||
\end{document}
|
||||
@ -88,22 +88,28 @@
|
||||
|
||||
|
||||
\section{Transaktionen}
|
||||
Zunächst betrachten wir den Stromausfall zum Zeitpunkt A. Daraus ergeben sich mehrere Fälle.
|
||||
Zunächst betrachten wir den Stromausfall zum Zeitpunkt A. Daraus ergeben sich mehrere Fälle. Die ersten beiden Fälle betrachten immer ein Datenbanksystem, die letzten beiden immer ein Dateisystem.
|
||||
|
||||
\begin{itemize}
|
||||
\item Es gibt kein Datenbanksystem und die Daten wurden nicht auf die Platte geschrieben. In diesem Fall hat der Ausfall keine negativen Folgen, da die Daten sich in einem konsistenten Zustand befinden.
|
||||
\item Es gibt ein Datenbanksystem und die Daten wurden nicht auf die Platte geschrieben. In diesem Fall hat der Ausfall ebenfalls keine negativen Folgen, da die Transaktion ohnehin nicht beendet war und damit keine Veränderungen hätten vorgenommen werden dürfen.
|
||||
\item Es gibt kein Datenbanksystem und die Daten wurden auf die Platte geschrieben. In diesem Fall befinden sich die Daten in einem inkonsistenten Zustand, da zwar der Saldo bei dem einen Konto verringert, bei dem anderen aber nicht erhöht wurde. Da es kein DBS gibt, kann dieser inkonsistente Zustand nicht leicht behoben werden.
|
||||
\item Es gibt ein Datenbanksystem und die Daten wurden auf die Platte geschrieben. In diesem Fall kann das DBS aufgrund von Logs nachvollziehen, dass die Transaktion noch nicht beendet war und wird die Veränderung an dem Saldo von Konto 5 rückgängig machen.
|
||||
\item Das System hat die Änderung am Konto mit der ID 5 nicht persistent gespeichert. Sie bleibt also im Hauptspeicher, bzw. wird daraus gelöscht bei dem Stromausfall. Somit wird die Überweisung nicht durchgeführt und es herrscht der Ausgangszustand.
|
||||
|
||||
\item Das System hat die Änderungen am Konto mit der ID 5 persistent gespeichert. Die Daten werden auf die Festplatte geschrieben. Es gibt nach der Abbuchung der 1000 Euro einen Stromausfall. Das System "`merkt"' sich diesen Zeitpunkt. Nach erneutem Start des Systems wird der letzte bekannte Zustand rekonstruiert und danach in den Ausgangszustand zurück versetzt.
|
||||
|
||||
\item Das System hat die Änderung am Konto mit der ID 5 noch nicht persistent gespeichert. Sie bleibt also im Hauptspeicher, bzw. wird daraus gelöscht bei dem Stromausfall. Somit wird die Überweisung nicht durchgeführt und es herrscht der Ausgangszustand.
|
||||
|
||||
\item Das System hat die Änderung am Konto mit der ID 5 persistent gespeichert. Also die Daten bereits auf die Festplatte geschrieben. Somit werden 1000 Euro vom Konto mit der ID 5 abgebucht. Da aber kein Datenbanksystem verwendet wird, gibt es keinen Wiederaufnahmepunkt, an welchem das System wiedereinsteigen könnte. Somit werden keine 1000 Euro dem Konto mit der ID 7 gutgeschrieben und das Geld ist weg.
|
||||
\end{itemize}
|
||||
|
||||
Anschließend betrachten wir den Stromausfall zum Zeitpunkt B.
|
||||
Anschließend betrachten wir den Stromausfall B.
|
||||
|
||||
\begin{itemize}
|
||||
\item Es gibt kein DBS und die geänderten Zustände von Konto 5 und 7 wurden auf die Platte geschrieben. In diesem Fall befinden sich beide Daten in einem konsistenten Zustand und es muss lediglich noch der Kontostand von Konto 5 ausgegeben werden.
|
||||
\item Es gibt ein DBS und die geänderten Zustände von Konto 5 und 7 wurden auf die Platte geschrieben. In diesem Fall befinden sich die Daten in einem konsistenten Zustand aber das DBS wird die Änderungen rückabwickeln, da die Transaktion nicht beendet wurde.
|
||||
\item Es gibt kein DBS und nur die Änderungen an Konto 7 sind persistiert. In diesem Fall befinden sich die Daten in einem inkonsistenten Zustand, da die Änderung an Konto 5 verloren gegangen ist.
|
||||
\item Es gibt ein DBS und nur die Änderungen an Konto 7 sind peristiert. In diesem Fall befinden sich die Daten in einem inkonsistenten Zustand, aber das DBS wird die Änderungen an Konto 7 rückabwickeln und die Daten wieder in einen konsistenten Zustand bringen.
|
||||
\item Das System hat die Änderung an beiden Konten nicht persistent gespeichert. Sie bleibt also im Hauptspeicher; bzw. wird daraus gelöscht bei dem Stromausfall. Somit wird die Überweisung nicht durchgeführt und es herrscht der Ausgangszustand. Es gibt aber eine falsche Meldung dem Clienten gegenüber für den Kontostand des Kontos mit der ID 7.
|
||||
|
||||
\item Das System hat die Änderungen an beiden Konten persistent gespeichert. Die Daten werden auf die Festplatte geschrieben. Es gibt nach der Überweisung einen Stromausfall. Jedoch wurde der Print Vorgang für das Konto mir der ID 5 nicht abgeschlossen. Dieser würde eine benutzerdefinierte Meldung an den Clienten zurückgeben. Da der Komplette Vorgang noch nicht abgeschlossen war werden beide Konten wieder in ihren Ausgangszustand zurück versetzt. Es gibt somit aber eine falsche Meldung dem Clienten gegenüber für den Kontostand des Kontos mit der ID 7.
|
||||
|
||||
\item Das System hat die Änderungen an beiden Konten nicht persistent gespeichert. Sie bleibt also im Hauptspeicher, bzw. wird daraus gelöscht bei dem Stromausfall. Somit wird die Überweisung nicht durchgeführt und es herrscht der Ausgangszustand. Es gibt somit aber eine falsche Meldung dem Clienten gegenüber für den Kontostand des Kontos mit der ID 7.
|
||||
|
||||
\item Das System hat die Änderungen an beiden Konten persistent gespeichert. Somit werden an beiden Konten die richtigen Aktionen durchgeführt. Das Konto mit der ID 5 wird mit 1000 Euro belastet und das Konto mit der ID 7 werden 1000 Euro gutgeschrieben. Jedoch gibt es vor dem Printbefehl für das Konto mit der ID 5 den Stromausfall. Der letzte Zustand kann nicht wiederhergestellt werden und somit fehlt dieser Print Befehl und der Client bekommt den falschen Kontostand für dieses Konto angezeigt.
|
||||
\end{itemize}
|
||||
|
||||
Zusammenfassend kann gesagt werden, dass es bei einem Datenbanksystem zu jedem Zeitpunkt immer nur konsistente Daten gibt. Bei einem reinen Dateisystem können die Daten hingegen inkonsistent zurückgelassen werden.
|
||||
|
||||
@ -149,10 +149,10 @@ Stephan Niendorf (6242417)}
|
||||
(x_{1}, x_{2}) &=& \left(\frac{1}{3} + \frac{1}{3}t, \frac{7}{3} + \frac{4}{3}t\right) \\
|
||||
&=& \left(\frac{1}{3}, \frac{7}{3}\right) + t\left(\frac{1}{3}, \frac{4}{3}\right)
|
||||
\end{alignat*}
|
||||
\begin{alignat*}{2}
|
||||
(x_{3}, x_{2}) &=& \left(t, \frac{7}{3} + \frac{4}{3}t\right) \\
|
||||
&=& \left(0, \frac{7}{3}\right) + t\left(1, \frac{4}{3}\right)
|
||||
\end{alignat*}
|
||||
%\begin{alignat*}{2}
|
||||
% (x_{3}, x_{2}) &=& \left(t, \frac{7}{3} + \frac{4}{3}t\right) \\
|
||||
% &=& \left(0, \frac{7}{3}\right) + t\left(1, \frac{4}{3}\right)
|
||||
%\end{alignat*}
|
||||
|
||||
Da in diesem Fall $x_{1}$ eine Basisvariable ist und somit nicht gleich $t$ ist, stellt $t$ eine beliebige positive Konstante dar. Daher verändert sich auch die Gerade je nach Wahl von $t$. Deswegen ist es nicht möglich genau eine Halbgerade zu finden, auf der die Zielfunktion beliebig große Werte annimmt.
|
||||
\subsection{} %b
|
||||
@ -180,7 +180,7 @@ Stephan Niendorf (6242417)}
|
||||
\addplot[no marks, black, -] expression[domain=0:6,samples=100]{4*x + 1} node[pos=0.65,anchor=north]{};
|
||||
\addplot[no marks, black, -] expression[domain=0:6,samples=100]{1*x + 2} node[pos=0.65,anchor=north]{};
|
||||
\addplot[no marks, black, -] expression[domain=0:6,samples=100]{0.5*x - 1} node[pos=0.65,anchor=north]{};
|
||||
\addplot[no marks, black, -] expression[domain=0:6,samples=100]{1.333333333333333*x + 2.33333333333333333} node[pos=0.65,anchor=north]{};
|
||||
%\addplot[no marks, black, -] expression[domain=0:6,samples=100]{1.333333333333333*x + 2.33333333333333333} node[pos=0.65,anchor=north]{};
|
||||
%\node at (axis cs: 2.5,4.5) {(2.25,3.75)};
|
||||
%\node at (axis cs: 6,2) {z};
|
||||
%\draw[>=stealth] (axis cs:1,0) -- (axis cs:1,-6) node [pos=0.65,anchor=north]{};
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
#|
|
||||
SE 3 Funktional Blatt 1
|
||||
Abgebende: Jim 2martens, 2noack, 0giebel
|
||||
Abgebende: Jim 2martens, Britta 2noack, Jan-Simon 0giesel
|
||||
|#
|
||||
|
||||
; 1.1
|
||||
|
||||
Reference in New Issue
Block a user