Added computational performance section; minor other changes

latex/thesis/chapters/proximal_decoding.tex

@@ -246,7 +246,7 @@ return $\boldsymbol{\hat{c}}$
 
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\section{Implementation Details (``A Selection of Implementation Considerations?'')}%
+\section{Implementation Details}%
 \label{sec:prox:Implementation Details}
 
 The algorithm was first implemented in Python because of the fast development
@@ -1248,12 +1248,60 @@ returning an invalid codeword.
 
 \subsection{Computational Performance}
 
-\begin{itemize}
+In order to determine the time complexity of proximal decoding for an
-    \item Theoretical analysis
+\ac{AWGN} channel, the decoding process as depicted in algorithm
-    \item Simulation results to substantiate theoretical analysis
+\ref{alg:prox} is considered.
-    \item Conclusion: $\mathcal{O}\left( n \right)$ time complexity, implementation heavily
+
-        optimizable
+When dealing with \ac{LDPC} codes, i.e., the number of non-zero entries in the
-\end{itemize}
+parity-check matrix $\boldsymbol{H}$ grows linearly
+with $n$, the two
+recursive steps in lines 3 and 4 have time complexity
+$\mathcal{O}\left( n \right)$ \cite[Sec. 4.1]{proximal_paper}.
+The $\text{sign}$ operation in line 5 also has $\mathcal{O}\left( n \right) $
+time complexity as it only depends on the $n$ components of $\boldsymbol{s}$.
+Given the sparsity of the matrix $\boldsymbol{H}$, evaluating the parity-check
+condition has linear time complexity as well, since at most $n$ additions and
+multiplications have to be performed.
+This means that the overall time complexity of proximal decoding for \ac{LDPC}
+codes in an \ac{AWGN} channel is $\mathcal{O}\left( n \right)$, which is
+practical since it is the same as that of $\ac{BP}$.
+
+This theoretical analysis is also corroborated by the practical results shown
+in figure \ref{fig:prox:time_comp}. \todo{Note about no very large $n$ codes being
+used due to memory requirements?}
+Some deviations from linear behaviour are unavoidable because not all codes
+considered are actually \ac{LDPC} codes, or \ac{LDPC} codes constructed
+according to the same scheme.
+Nontheless, a generally linear relationship between the average time needed to
+decode a received frame and the length $n$ of the frame can be observed.
+
+\begin{figure}[H]
+    \centering
+
+    \begin{tikzpicture}
+        \begin{axis}[grid=both,
+                     xlabel={$n$}, ylabel={Time per frame (s)},
+                     width=0.6\textwidth,
+                     height=0.45\textwidth,
+                     legend cell align={left},]
+
+            \addplot[RedOrange, only marks, mark=*]
+                table [col sep=comma, x=n, y=spf]
+                    {res/proximal/fps_vs_n.csv};
+        \end{axis}
+    \end{tikzpicture}
+
+    \caption{Time requirements of proximal decoding algorithm imlementation%
+        \protect\footnotemark{}}
+    \label{fig:prox:time_comp}
+\end{figure}%
+%
+\footnotetext{The datapoints depicted were calculated by evaluating the
+    metadata of \ac{FER} simulation results from the following codes:
+    BCH (31, 11); BCH (31, 26); \cite[\text{96.3.965; 204.33.484; 204.55.187;
+    408.33.844; PEGReg252x504}]{mackay_enc}
+}%
+%
 
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -1271,7 +1319,7 @@ a limited number of possible results (``ML-in-the-List'' as it will
 subsequently be called) to improve the decoding performance.
 This concept is pursued in this section.
 
-First, a guideline has to be found with which to assess the probability that
+First, a guideline has to be found with which to evaluate the probability that
 a given component of an estimate is wrong.
 One compelling observation is that the closer an estimate is to being at a
 valid codeword, the smaller the magnitude of the gradient of the
@@ -1310,6 +1358,9 @@ error are strongly correlated, a relationship depicted in figure
     \label{fig:prox:correlation}
 \end{figure}
 
+\todo{Mention that the variance of the oscillation is measured
+after a given number of iterations}
+
 \noindent The y-axis depicts whether there is a bit error and the x-axis the
 variance in $\nabla h\left( \tilde{\boldsymbol{x}} \right)$ past the iteration
 $k=100$. While this is not exactly the magnitude of the oscillation, it is
@@ -1327,6 +1378,7 @@ Its only difference to algorithm \ref{alg:prox} is that instead of returning
 the last estimate when no valid result is reached, an ML-in-the-List step is
 performed.
 
+\begin{minipage}{\linewidth}
     \begin{genericAlgorithm}[caption={Improved proximal decoding algorithm},
         label={alg:prox:improved},]
 $\boldsymbol{s} \leftarrow \boldsymbol{0}$
@@ -1346,6 +1398,7 @@ $\textcolor{KITblue}{\text{Compute }d_H\left( \boldsymbol{ \tilde{c}}_l,
 $\textcolor{KITblue}{\text{Output }\boldsymbol{\tilde{c}}_l\text{ with lowest }
     d_H\left( \boldsymbol{ \tilde{c}}_l, \boldsymbol{\hat{c}} \right)}$
         \end{genericAlgorithm}
+\end{minipage}
 
 \todo{Not hamming distance, correlation}
 
@@ -1513,7 +1566,7 @@ average time needed to decode a single received frame is visualized for
 proximal decoding as well as for the improved algorithm.
 It should be noted that some variability in the data is to be expected,
 since the timing of the actual simulations depends on a multitude of other
-parameters, such as the outside temperature (because of thermal throttling),
+parameters such as the outside temperature (because of thermal throttling),
 the scheduling choices of the operating system as well as variations in the
 implementations themselves.
 Nevertheless, the empirical data serves, at least in part, to validate the