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

Ran proximal decoding chapter through spellcheck

Browse Source
This commit is contained in:
Andreas Tsouchlos 2023-04-11 21:45:41 +02:00
parent 5989c33621
commit 7a6968d0ca
1 changed files with 29 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -4,7 +4,7 @@
In this chapter, the proximal decoding algorithm is examined.
First, the algorithm itself is described.
Then, some interesting ideas concerning the implementation are presented.
Simulation results are shown, on the basis of which the behaviour of the
Simulation results are shown, based on which the behavior of the
algorithm is investigated for different codes and parameters.
Finally, an improvement on proximal decoding is proposed.
@ -257,7 +257,7 @@ It was subsequently reimplemented in C++ using the Eigen%
\footnote{\url{https://eigen.tuxfamily.org}}
linear algebra library to achieve higher performance.
The focus has been set on a fast implementation, sometimes at the expense of
memory usage, somewhat limiting the size of the codes the implemenation can be
memory usage, somewhat limiting the size of the codes the implementation can be
used with.
The evaluation of the simulation results has been wholly realized in Python.
@ -319,11 +319,11 @@ $[-\eta, \eta]$ individually.
\section{Analysis and Simulation Results}%
\label{sec:prox:Analysis and Simulation Results}
In this section, the general behaviour of the proximal decoding algorithm is
In this section, the general behavior of the proximal decoding algorithm is
analyzed.
The impact of the parameters $\gamma$, as well as $\omega$, $K$ and $\eta$ is
examined.
The decoding performance is assessed on the basis of the \ac{BER} and the
The decoding performance is assessed based on the \ac{BER} and the
\ac{FER} as well as the \textit{decoding failure rate} - the rate at which
the algorithm produces invalid results.
The convergence properties are reviewed and related to the decoding
@ -414,7 +414,7 @@ while the newly generated ones are shown with dashed lines.
\noindent It is noticeable that for a moderately chosen value of $\gamma$
($\gamma = 0.05$) the decoding performance is better than for low
($\gamma = 0.01$) or high ($\gamma = 0.15$) values.
The question arises whether there is some optimal value maximazing the decoding
The question arises whether there is some optimal value maximizing the decoding
performance, especially since it seems to dramatically depend on $\gamma$.
To better understand how they are
related, figure \ref{fig:prox:results} was recreated, but with a considerably
@ -484,7 +484,7 @@ Rather, a preliminary examination providing a rough window for $\gamma$ may
be sufficient.
When examining a number of different codes (figure
\ref{fig:prox:results_3d_multiple}), it is apparent that while the exact
landscape of the graph depends on the code, the general behaviour is the same
landscape of the graph depends on the code, the general behavior is the same
in each case.
The parameter $\gamma$ describes the step-size for the optimization step
@ -496,7 +496,7 @@ The relationship between $\omega$ and $\gamma$ is portrayed in figure
The color of each cell indicates the \ac{BER} when the corresponding values
are chosen for the parameters.
The \ac{SNR} is kept constant at $\SI{4}{dB}$.
The \ac{BER} exhibits similar behaviour in its dependency on $\omega$ and
The \ac{BER} exhibits similar behavior in its dependency on $\omega$ and
on $\gamma$: it is minimized when keeping the value within certain
bounds, without displaying a single clear optimum.
It is noteworthy that the decoder seems to achieve the best performance for
@ -551,8 +551,8 @@ depicted in figure \ref{fig:prox:gamma_omega_multiple}.
To better understand how to determine the optimal value for the parameter $K$,
the average error is inspected.
This time $\gamma$ and $\omega$ are held constant at $0.05$ and the average
error is observed during each iteration of the decoding process, for a number
of different \acp{SNR}.
error is observed during each iteration of the decoding process, for several
different \acp{SNR}.
The plots have been generated by averaging the error over $\SI{500000}{}$
decodings.
As some decodings go one for more iterations than others, the number of values
@ -566,7 +566,7 @@ timing requirements of the decoding process.
Another aspect to consider is that the higher the \ac{SNR}, the fewer
decodings are present at each iteration
to average, since a solution is found earlier.
This explains the decreasing smootheness of the lines as the \ac{SNR} rises.
This explains the decreasing smoothness of the lines as the \ac{SNR} rises.
Remarkably, the \ac{SNR} seems to not have any impact on the number of
iterations necessary to reach the point at which the average error
stabilizes.
@ -713,18 +713,18 @@ means to bring about numerical stability.
Until now, only the \ac{BER} has been considered to gauge the decoding
performance.
The \ac{FER}, however, shows considerably worse behaviour, as can be seen in
The \ac{FER}, however, shows considerably worse behavior, as can be seen in
figure \ref{fig:prox:ber_fer_dfr}.
Besides the \ac{BER} and \ac{FER} curves, the figure also shows the
\textit{decoding failure rate}.
This is the rate at which the iterative process produces invalid codewords,
i.e., the stopping criterion (line 6 of algorithm \ref{alg:prox}) is never
satisfied and the maximum number of itertations $K$ is reached without
satisfied and the maximum number of iterations $K$ is reached without
converging to a valid codeword.
Three lines are plotted in each case, corresponding to different values of
the parameter $\gamma$.
The values chosen are the same as in figure \ref{fig:prox:results}, as they
seem to adequately describe the behaviour across a wide range of values
seem to adequately describe the behavior across a wide range of values
(see figure \ref{fig:prox:results_3d}).
It is apparent that the \ac{FER} and the decoding failure rate are extremely
@ -974,14 +974,14 @@ polynomial, which influence the next estimate.
iterations, the estimate starts to oscillate around a particular value.
Jointly, the two gradients stop further approaching the value
zero.
This leads to the two terms of the objective function an in particular the
This leads to the two terms of the objective function and in particular the
code-constraint polynomial not being minimized.
As such, the constraints are not being satisfied and the estimate is not
converging towards a valid codeword.
While figure \ref{fig:prox:convergence} shows only one instance of a decoding
task, with no statistical significance, it is indicative of the general
behaviour of the algorithm.
behavior of the algorithm.
This can be justified by looking at the gradients themselves.
In figure \ref{fig:prox:gradients} the gradients of the negative
log-likelihood and the code-constraint polynomial for a repetition code with
@ -1096,7 +1096,7 @@ still yielding an invalid codeword.
The higher the \ac{SNR}, the more likely the gradient of the negative
log-likelihood is to point to a valid codeword.
The common component of the two gradient then pulls the estimate closer to
The common component of the two gradients then pulls the estimate closer to
a valid codeword before the oscillation takes place.
This explains why the decoding performance is so much better for higher
\acp{SNR}.
@ -1111,13 +1111,13 @@ $h \left( \tilde{\boldsymbol{x}} \right)$ dominating the landscape of the
objective function, thereby introducing these local minima into the objective
function.
When considering codes with larger $n$ the behaviour generally stays the
When considering codes with larger $n$ the behavior generally stays the
same, with some minor differences.
In figure \ref{fig:prox:convergence_large_n} the decoding process is
visualized for one component of a code with $n=204$, for a single decoding.
The two gradients still eventually oppose each other and the estimate still
starts to oscillate, the same as illustrated in figure
\ref{fig:prox:convergence} on the basis of a code with $n=7$.
\ref{fig:prox:convergence} based on a code with $n=7$.
However, in this case, the gradient of the code-constraint polynomial iself
starts to oscillate, its average value being such that the effect of the
gradient of the negative log-likelihood is counteracted.
@ -1190,10 +1190,10 @@ 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}.
Some deviations from linear behaviour are unavoidable because not all codes
Some deviations from linear behavior 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
Nonetheless, a generally linear relationship between the average time needed to
decode a received frame and the length $n$ of the frame can be observed.
These results were generated on an Intel Core i7-7700HQ 4-core CPU, running at
$\SI{2.80}{GHz}$ and utilizing all cores.
@ -1242,12 +1242,12 @@ 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 evaluate the probability that
First, a guideline must 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
code-constraint polynomial, as illustrated in figure \ref{fig:prox:gradients}.
This gives rise to the notion that some property or behaviour of
This gives rise to the notion that some property or behavior of
$\nabla h\left( \tilde{\boldsymbol{x}} \right) $ may be related in its
magnitude to the confidence that a given bit is correct.
And indeed, the magnitude of the oscillation of
@ -1299,7 +1299,7 @@ The datapoints are taken from a single decoding operation
Using this observation as a rule to determine the $N\in\mathbb{N}$ most
probably wrong bits, all variations of the estimate with those bits modified
can be generated.
An \ac{ML}-in-the-List step can then be performed in order to determine the
An \ac{ML}-in-the-List step can then be performed to determine the
most likely candidate.
This process is outlined in algorithm \ref{alg:prox:improved}.
Its only difference to algorithm \ref{alg:prox} is that instead of returning
@ -1331,14 +1331,14 @@ $\textcolor{KITblue}{\text{Output }\boldsymbol{\tilde{c}}_l\text{ with lowest }
Figure \ref{fig:prox:improved_results} shows the gain that can be achieved
when the number $N$ is chosen to be 12.
Again, three values of gamma are chosen, for which the \ac{BER}, \ac{FER}
and decoding failure rate is plotted.
and decoding failure rate are plotted.
The simulation results for the original proximal decoding algorithm are shown
with solid lines and the results for the improved version are shown with
dashed lines.
For the case of $\gamma = 0.05$, the number of frame errors produced for the
datapoints at $\SI{6}{dB}$, $\SI{6.5}{dB}$ and $\SI{7}{dB}$ are
70, 17 and 2, respectively.
The gain seems to depend on the value of $\gamma$, as well as become more
The gain seems to depend on the value of $\gamma$, as well as becoming more
pronounced for higher \ac{SNR} values.
This is to be expected, since with higher \ac{SNR} values the number of bit
errors decreases, making the correction of those errors in the ML-in-the-List
@ -1347,12 +1347,12 @@ In figure \ref{fig:prox:improved:comp} the decoding performance
between proximal decoding and the improved algorithm is compared for a number
of different codes.
In the case of the code with $n=504$ shown in figure
\ref{fig:prox:improved:comp:504}, only 76 frame errors where produced to
\ref{fig:prox:improved:comp:504}, only 76 frame errors were produced to
generate the point for the improved algorithm for $\gamma=0.05$ at
$\SI{5.5}{dB}$.
Similar behaviour can be observed in all cases, with varying improvement over
Similar behavior can be observed in all cases, with varying improvement over
standard proximal decoding.
In some cases, a gain of up to $\SI{1}{dB}$ and higher can be achieved.
In some cases, a gain of up to $\SI{1}{dB}$ or higher can be achieved.
\begin{figure}[h]
\centering
@ -1535,6 +1535,6 @@ by appending an ML-in-the-List step when the algorithm does not produce a
valid result.
The gain can in some cases be as high as $\SI{1}{dB}$ and is achievable with
negligible computational performance penalty.
The improvement is mainly noticable for higher \ac{SNR} values and depends on
The improvement is mainly noticeable for higher \ac{SNR} values and depends on
the code as well as the chosen parameters.