an.tsouchlos/ba-thesis
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

Added computational performance section; minor other changes

Browse Source
This commit is contained in:
Andreas Tsouchlos 2023-04-10 15:54:11 +02:00
parent b1f6a098bb
commit 501dcc341f
1 changed files with 64 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

75
latex/thesis/chapters/proximal_decoding.tex
View File

@ -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}
\item Theoretical analysis
\item Simulation results to substantiate theoretical analysis
\item Conclusion: $\mathcal{O}\left( n \right)$ time complexity, implementation heavily
optimizable
\end{itemize}
In order to determine the time complexity of proximal decoding for an
\ac{AWGN} channel, the decoding process as depicted in algorithm
\ref{alg:prox} is considered.
When dealing with \ac{LDPC} codes, i.e., the number of non-zero entries in the
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,7 +1378,8 @@ 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{genericAlgorithm}[caption={Improved proximal decoding algorithm},
\begin{minipage}{\linewidth}
\begin{genericAlgorithm}[caption={Improved proximal decoding algorithm},
label={alg:prox:improved},]
$\boldsymbol{s} \leftarrow \boldsymbol{0}$
for $K$ iterations do
@ -1345,7 +1397,8 @@ $\textcolor{KITblue}{\text{Compute }d_H\left( \boldsymbol{ \tilde{c}}_l,
\boldsymbol{\hat{c}} \right) \text{ for all valid codewords } \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{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