Is this the end?

Session.vim

@@ -13,14 +13,17 @@ if &shortmess =~ 'A'
 else
   set shortmess=aoO
 endif
-badd +183 content/BACH.typ
+badd +353 content/BACH.typ
 badd +1 glossary.typ
 badd +1 bibliography.bib
 badd +1 \$
-badd +14 pseudocode/bach_1.typ
+badd +9 pseudocode/bach_1.typ
 badd +265 content/SMHD.typ
-badd +7 pseudocode/bach_find_best_appr.typ
+badd +3 pseudocode/bach_find_best_appr.typ
-badd +60 content/introduction.typ
+badd +65 content/introduction.typ
+badd +16 graphics/quantizers/bach/sign-based-overlay.typ
+badd +34 content/conclusion.typ
+badd +5 content/outlook.typ
 argglobal
 %argdel
 set stal=2
@@ -28,6 +31,9 @@ tabnew +setlocal\ bufhidden=wipe
 tabnew +setlocal\ bufhidden=wipe
 tabnew +setlocal\ bufhidden=wipe
 tabnew +setlocal\ bufhidden=wipe
+tabnew +setlocal\ bufhidden=wipe
+tabnew +setlocal\ bufhidden=wipe
+tabnew +setlocal\ bufhidden=wipe
 tabrewind
 edit content/BACH.typ
 argglobal
@@ -42,12 +48,51 @@ setlocal fdn=20
 setlocal fen
 silent! normal! zE
 let &fdl = &fdl
-let s:l = 88 - ((17 * winheight(0) + 25) / 50)
+let s:l = 309 - ((0 * winheight(0) + 28) / 57)
 if s:l < 1 | let s:l = 1 | endif
 keepjumps exe s:l
 normal! zt
-keepjumps 88
+keepjumps 309
-normal! 0102|
+normal! 020|
+tabnext
+edit content/conclusion.typ
+argglobal
+setlocal fdm=manual
+setlocal fde=0
+setlocal fmr={{{,}}}
+setlocal fdi=#
+setlocal fdl=0
+setlocal fml=1
+setlocal fdn=20
+setlocal fen
+silent! normal! zE
+let &fdl = &fdl
+let s:l = 19 - ((18 * winheight(0) + 28) / 57)
+if s:l < 1 | let s:l = 1 | endif
+keepjumps exe s:l
+normal! zt
+keepjumps 19
+normal! 0
+tabnext
+edit content/outlook.typ
+argglobal
+balt content/conclusion.typ
+setlocal fdm=manual
+setlocal fde=0
+setlocal fmr={{{,}}}
+setlocal fdi=#
+setlocal fdl=0
+setlocal fml=1
+setlocal fdn=20
+setlocal fen
+silent! normal! zE
+let &fdl = &fdl
+let s:l = 5 - ((4 * winheight(0) + 28) / 57)
+if s:l < 1 | let s:l = 1 | endif
+keepjumps exe s:l
+normal! zt
+keepjumps 5
+normal! 097|
 tabnext
 edit content/introduction.typ
 argglobal
@@ -62,12 +107,12 @@ setlocal fdn=20
 setlocal fen
 silent! normal! zE
 let &fdl = &fdl
-let s:l = 56 - ((41 * winheight(0) + 25) / 50)
+let s:l = 74 - ((46 * winheight(0) + 28) / 57)
 if s:l < 1 | let s:l = 1 | endif
 keepjumps exe s:l
 normal! zt
-keepjumps 56
+keepjumps 74
-normal! 0
+normal! 084|
 tabnext
 edit glossary.typ
 argglobal
@@ -126,8 +171,8 @@ set winminheight=0
 set winheight=1
 set winminwidth=0
 set winwidth=1
-exe '1resize ' . ((&lines * 25 + 26) / 53)
+exe '1resize ' . ((&lines * 25 + 30) / 60)
-exe '2resize ' . ((&lines * 24 + 26) / 53)
+exe '2resize ' . ((&lines * 31 + 30) / 60)
 argglobal
 balt bibliography.bib
 setlocal fdm=manual
@@ -140,12 +185,12 @@ setlocal fdn=20
 setlocal fen
 silent! normal! zE
 let &fdl = &fdl
-let s:l = 12 - ((11 * winheight(0) + 12) / 25)
+let s:l = 14 - ((13 * winheight(0) + 12) / 25)
 if s:l < 1 | let s:l = 1 | endif
 keepjumps exe s:l
 normal! zt
-keepjumps 12
+keepjumps 14
-normal! 068|
+normal! 010|
 wincmd w
 argglobal
 if bufexists(fnamemodify("pseudocode/bach_find_best_appr.typ", ":p")) | buffer pseudocode/bach_find_best_appr.typ | else | edit pseudocode/bach_find_best_appr.typ | endif
@@ -163,16 +208,36 @@ setlocal fdn=20
 setlocal fen
 silent! normal! zE
 let &fdl = &fdl
-let s:l = 7 - ((6 * winheight(0) + 12) / 24)
+let s:l = 4 - ((3 * winheight(0) + 15) / 31)
 if s:l < 1 | let s:l = 1 | endif
 keepjumps exe s:l
 normal! zt
-keepjumps 7
+keepjumps 4
-normal! 031|
+normal! 014|
 wincmd w
-exe '1resize ' . ((&lines * 25 + 26) / 53)
+exe '1resize ' . ((&lines * 25 + 30) / 60)
-exe '2resize ' . ((&lines * 24 + 26) / 53)
+exe '2resize ' . ((&lines * 31 + 30) / 60)
-tabnext 5
+tabnext
+edit graphics/quantizers/bach/sign-based-overlay.typ
+argglobal
+balt pseudocode/bach_1.typ
+setlocal fdm=manual
+setlocal fde=0
+setlocal fmr={{{,}}}
+setlocal fdi=#
+setlocal fdl=0
+setlocal fml=1
+setlocal fdn=20
+setlocal fen
+silent! normal! zE
+let &fdl = &fdl
+let s:l = 16 - ((15 * winheight(0) + 25) / 50)
+if s:l < 1 | let s:l = 1 | endif
+keepjumps exe s:l
+normal! zt
+keepjumps 16
+normal! 026|
+tabnext 2
 set stal=1
 if exists('s:wipebuf') && len(win_findbuf(s:wipebuf)) == 0 && getbufvar(s:wipebuf, '&buftype') isnot# 'terminal'
   silent exe 'bwipe ' . s:wipebuf
@@ -180,8 +245,6 @@ endif
 unlet! s:wipebuf
 set winheight=1 winwidth=20
 let &shortmess = s:shortmess_save
-let &winminheight = s:save_winminheight
-let &winminwidth = s:save_winminwidth
 let s:sx = expand("<sfile>:p:r")."x.vim"
 if filereadable(s:sx)
   exe "source " . fnameescape(s:sx)

content/BACH.typ

@@ -1,10 +1,13 @@
 #import "@preview/glossarium:0.4.1": *
+#import "@preview/tablex:0.0.8": tablex, rowspanx, colspanx
 
-= Boundary Adaptive Clustering with Helper Data
+= Boundary Adaptive Clustering with Helper Data (BACH)
-
-Instead of generating helper-data to improve the quantization process itself, like in #gls("smhdt"), or using some kind of error correcting code after the quantization process, we can also try to find helper-data before performing the quantization that will optimize our input values before quantizing them to minimize the risk of bit and symbol errors during the reconstruction phase. 
 
+//Instead of generating helper-data to improve the quantization process itself, like in #gls("smhdt"), or using some kind of error correcting code after the quantization process, we can also try to find helper-data before performing the quantization that will optimize our input values before quantizing them to minimize the risk of bit and symbol errors during the reconstruction phase. 
 
+We can explore the option of finding helper data before performing the quantization process.
+This approach  aims to optimize our input values prior to quantization, which may help minimize the risk of bit and symbol errors during the reconstruction phase. 
+This differs from methods like @smhdt, which generate helper data to improve the quantization process itself, of those that apply error-correcting codes afterward.
 
 Since this #gls("hda") modifies the input values before the quantization takes place, we will consider the input values as zero-mean Gaussian distributed and not use a CDF to transform these values into the tilde-domain.
 
@@ -22,11 +25,12 @@ Considering that the margin of error of the value $x$ is comparable with the one
 This means that the quantizer used here is very unreliable as is.
 
 Now, to increase the reliability of this quantizer, we can try to move our input values further away from the value $x = 0$. 
-To do so, we can define a new input value $z$ as a linear combination of two realizations of $X$, $x_1$ and $x_2$ with a set of weights $h_1$ and $h_2$: 
+To do so, we can define a new input value $z$ as a linear combination of two realizations of $X$, $x_1$ and $x_2$ with a set of weights $h_1$ and $h_2$ that we will use as helper data: 
 $
-z = h_1 dot x_1 + h_2 dot x_2 .
+z = h_1 dot x_1 + h_2 dot x_2 ,
 $<eq:lin_combs>
 
+with $h_i in {plus.minus 1}$. Building only the sum of two input values $x_1 + x_2$ is not sufficient here, since the resulting distribution would be a normal distribution with $mu = 0$ as well.
 === Derivation of the resulting distribution
 
 To find a description for the random distribution $Z$ of $z$ we can interpret this process mathematically as a maximisation of a sum.
@@ -34,9 +38,9 @@ This can be realized by replacing the values of $x_i$ with their absolute values
 $
 z = abs(x_1) + abs(x_2) 
 $
-Taking into account, that $x_i$ are realizations of a normal distribution -- that we can assume without loss of generality to have its expected value at $x=0$ and a standard deviation of $sigma = 1$ -- we can define the overall resulting random distribution $Z$ to be: 
+Taking into account that $x_i$ are realizations of a normal distribution, we can assume without loss of generality that $X$ is i.i.d., /*to have its expected value at $x=0$ and a standard deviation of $sigma = 1$ --*/ defining the overall resulting random distribution $Z$ as: 
 $
-Z = abs(X) + abs(X).
+Z = abs(X_1) + abs(X_2).
 $<eq:z_distribution>
 We will redefine $abs(X)$ as a half-normal distribution $Y$ whose PDF is
 $
@@ -45,7 +49,7 @@ f_Y(y, sigma) &= frac(sqrt(2), sigma sqrt(pi)) lr(exp(-frac(y^2, 2 sigma^2)) mid
 $<eq:half_normal>
 Now, $Z$ simplifies to 
 $
-Z = Y + Y.
+Z = Y_1 + Y_2.
 $
 We can assume for now that the realizations of $Y$ are independent of each other.
 The PDF of the addition of these two distributions can be described through the convolution of their respective PDFs: 
@@ -77,17 +81,23 @@ $f_Z^* (z)$ now describes the final random distribution after the application of
 
 === Generating helper-data
 
-To find the optimal set of helper-data that will result in the distribution shown in @fig:z_pdf, we can define the vector of all possible linear combinations $bold(z)$ as the vector-matrix multiplication of the two input values $x_i$ and the matrix $bold(H)$ of all weight combinations: 
+To find the optimal set of helper-data that will result in the distribution shown in @fig:z_pdf, we can define the vector of all possible linear combinations $bold(z)$ as the vector-matrix multiplication of the input values $x_i$ and the matrix $bold(H)$ of all weight combinations with $h_i in [plus.minus 1]$: 
 $
 bold(z) &= bold(x) dot bold(H)\
-&= vec(x_1, x_2) dot mat(delim: "[", h_1, -h_1, h_1, -h_1; h_2, h_2, -h_2, -h_2)\
-&= vec(x_1, x_2) dot mat(delim: "[", +1, -1, +1, -1; +1, +1, -1, -1)
 $<eq:z_combinations>
 We will choose the optimal weights based on the highest absolute value of $bold(z)$, as that value will be the furthest away from $0$. 
-We may encounter two entries in $bold(z)$ that both have the same highest absolute value.
+//We may encounter two entries in $bold(z)$ that both have the same highest absolute value.
-In that case, we will choose the combination of weights randomly out of our possible options. 
+//In that case, we will choose the combination of weights randomly out of our possible options.
+To not encounter two entries in $bold(z)$ that both have the same highest absolute value, we can set the first helper data bit to be always $h_1 = 1$. 
 
-If we take a look at the dimensionality of the matrix of all weight combinations, we notice that we will need to store $log_2(2) = 1$ helper-data bit.
+Considering our single-bit quantization case, @eq:z_combinations can be written as: 
+
+$
+bold(z) = vec(x_1, x_2) dot mat(delim: "[", +1, -1, +1, -1; +1, +1, -1, -1)
+$
+
+The vector of optimal weights $bold(h_"opt")$ can now be found through $op("argmax")_h (bold(z))$.
+If we take a look at the dimensionality of the matrix of all weight combinations, we notice that we will need to store only $1$ helper-data bit per quantized symbol because $h_1$ is set to $1$.
 In fact, we will show later, that the amount of helper-data bits used by this HDA is directly linked to the number of input values used instead of the number of bits we want to extract during quantization.
 
 == Generalization to higher-order bit quantization
@@ -96,23 +106,28 @@ We can generalize the idea of @sect:1-bit-opt and apply it for a higher-order bi
 Contrary to @smhdt, we will always use the same step function as quantizer and optimize the input values $x$ to be the furthest away from any decision threshold.
 In this higher-order case, this means that we want to optimise our input values as far away as possible from the nearest decision threshold of the quantizer instead of just maximising the absolute value of the linear combination.
 
-For a complete generalization of this method, we will also parametrize the amount of addends in the linear combination of $z$.
+For a complete generalization of this method, we will also parametrize the amount of addends $N$ kin the linear combination of $z$.
-//Later we will be able to show that a higher number of summands for $z$ can provide better approximations for the ideal values of $z$ at the expense of the number of available input values for the quantizer. 
-
 That means we can define $z$ from now on as:
 $
-z = sum_(i=1)^(n>=2) x_i dot h_i
+z = sum_(i=1)^(N) x_i dot h_i
 $<eq:z_eq>
 
 
 
 We can define the condition to test whereas a tested linear combination is optimal as follows:\
 The optimal linear combination $z_"opt"$ is found, when the distance to the nearest quantizer decision bound is maximised. 
+Finding the weights $bold(h)_"opt"$ of the optimal linear combination $z_"opt"$ can be formalized as: 
+
+$
+bold(h)_"opt" = op("argmax")_h op("min")_j abs(bold(h)^T bold(x) - b_j) "s.t." h_j in {plus.minus 1}
+$<eq:optimization>
 
 ==== Example with 2-bit quantizer
 //Let's consider the following example using a 2-bit quantizer:\
 We can define the bounds of the two bit quantizer $bold(b)$ as $[-alpha, 0, alpha]$ omitting the bounds $plus.minus infinity$.
 The values of $bold(b)$ are already placed in the real domain to directly quantize normal distributed input values.
+A simple way to solve @eq:optimization is to use a brute force method and calculate all distances to every quantization bound $b_j$, because the number of possible combinations is finite.
+Furthermore, fining a solution for @eq:optimization analytically poses to be significantly more complex.
 
 The linear combination $z$ for the amount of addends $i = 2$ is defined as 
 $
@@ -144,47 +159,55 @@ $
 
 The optimal linear combination $z_"opt"$ can now be found as the entry $z_j$ of $bold(z)$ where its corresponding distance $nu_j$ is maximised.
 
-Two important points were anticipated in this example: 
+=== Simulation of the bound distance maximisation strategy<sect:instability_sim> 
+
+Two important points were anticipated in the preceding example: 
 1. We cannot define the resulting random distribution $Z$ after performing this operation analytically and thus also not the quantizer bounds $bold(b)$.
   A way to account for that is to guess the resulting random distribution and $bold(b)$ initially and repeating the optimization using quantizer bounds found through the @ecdf of the resulting linear combination values.
 2. If the optimization described above is repeated multiple times using an @ecdf, the resulting random distribution $Z$ must converge to a stable random distribution. Otherwise we will not be able to carry out a reliable quantization in which the symbols are uniformly distributed.
 
-=== Simulation of the bound distance maximisation strategy<sect:instability_sim> 
+To check that the strategy for optimizing the linear combination provided in the example above results in a converging random distribution, we will perform a simulation of the optimization as described in the example using $100 space.nobreak 000$ simulated normal distributed values as realizations of the standard normal distribution with the parameters $mu = 0$ and $sigma = 1$.
 
-To check that the strategy for optimizing the linear combination provided in the example above results in a converging random distribution, we will perform a simulation of the optimization as described in the example using $100,000$ simulated normal distributed values as realizations of the standard normal distribution with the parameters $mu = 0$ and $sigma = 1$.
+@fig:bach_instability shows various histograms of the vector $bold(z)_"opt"$ after different iterations.
+Even though the overall shape of the distribution comes close to our goal of moving the input values away from the quantizer bounds $bold(b)$, the distribution itself does not converge to one specific, final shape. 
+It seems that the resulting distributions for each iteration oscillate in some way, since the distributions for iterations $7$ and $25$ have the same shape.
+However the distribution seems to be chaotic and thus does not seem suitable for further quantization.
 
 #figure(
 grid(
   columns: (1fr, 1fr),
   rows: (2),
-  row-gutter: 5pt,
+  [//#figure(
-  figure(
+  #image("../graphics/plots/bach/instability/frame_1.png")
-    image("../graphics/plots/bach/instability/frame_1.png"),
+  #v(-2em)
-  ),
+  //)
-  figure(
+  Iteration 1],
-    image("../graphics/plots/bach/instability/frame_7.png"),
+  [//#figure(
-  ),
+  #image("../graphics/plots/bach/instability/frame_7.png")
-  figure(
+  #v(-2em)
-    image("../graphics/plots/bach/instability/frame_18.png"),
+  //)
-  ),
+  Iteration 7],
-  figure(
+  [//#figure(
-    image("../graphics/plots/bach/instability/frame_25.png"),
+  #image("../graphics/plots/bach/instability/frame_18.png")
-  )
+  #v(-2em)
+  //)
+  Iteration 18],
+  [//#figure(
+  #image("../graphics/plots/bach/instability/frame_25.png")
+  #v(-2em)
+  //)
+  Iteration 25]
 ),
   caption: [Probability distributions for various iterations]
 )<fig:bach_instability>
 
-@fig:bach_instability shows various histograms of the vector $bold(z)_"opt"$ after different iterations.
-Even though the overall shape of the distribution comes close to our goal of moving the input values away from the quantizer bounds $bold(b)$, the distribution itself does not converge to one specific, final shape. 
-It seems that the resulting distributions for each iteration oscillate in some way, since the distributions for iterations $7$ and $25$ have the same shape.
-However the distribution does not seem to be predictable on the basis of the index of the iteration.
 
 === Center Point Approximation 
 
 For that reason, we will now propose a different strategy to find the weights for the optimal linear combination $z_"opt"$.
-Instead of defining the desired outcome of $z_"opt"$ as the greatest distance to the nearest quantizer decision threshold, we will define a vector $bold(cal(o)) in.rev {cal(o)_1, cal(o)_2 ..., cal(o)_(2^M)}$ containing the optimal values that we want to approximate with $z$.
+Instead of defining the desired outcome of $z_"opt"$ as the greatest distance to the nearest quantizer decision threshold, we will define a vector $bold(cal(o)) = [cal(o)_1, cal(o)_2 ..., cal(o)_(2^M)]$ containing the optimal values that we want to approximate with $z$.
-Considering a m-bit quantizer with $2^m$ steps, we can define the values of $bold(cal(o))$ as the center points of these quantizer steps.
+Considering a M-bit quantizer with $2^M$ steps, we can define the values of $bold(cal(o))$ as the center points of these quantizer steps.
-Its cardinality is $2^M$, while $M$ defines the number of bits we want to extract through the quantization.
+Its cardinality is $2^M$.
 It has to be noted, that $bold(cal(o))$ consists of optimal values that we may not be able to exactly approximate using a linear combination based on weights and our given input values. 
 
 We can find the optimal linear combination $z_"opt"$ by finding the minimum of all distances to all optimal points defined in $bold(cal(o))$.
@@ -200,9 +223,9 @@ $
   include("../pseudocode/bach_find_best_appr.typ")
 )<alg:best_appr>
 
-@alg:best_appr shows a programmatic approach to find the set of weights for the best approximation. The algorithm returns a tuple consisting of the weight combination $bold(h)$ and the resulting value of the linear combination $z_"opt"$
+@alg:best_appr shows a programmatic approach to find the set of weights for the best approximation. The algorithm returns a tuple consisting of the weight combination $bold(h)$ and the resulting value of the linear combination $z_"opt"$.
 
-Because the superposition of different linear combinations of normal distributions corresponds to a Gaussian Mixture Model, wherein finding the ideal set of points $bold(cal(o))$ analytically is impossible.
+Because the superposition of different linear combinations of normal distributions corresponds to a Gaussian Mixture Model, finding the ideal set of points $bold(cal(o))$ analytically is impossible.
 
 Instead, we will first estimate $bold(cal(o))$ based on the normal distribution parameters after performing multiple convolutions with the input distribution $X$.
 The parameters of a multiple convoluted normal distribution is defined as: 
@@ -220,7 +243,7 @@ $<eq:z_dist_def>
 The parameters $mu_Z$ and $sigma_Z$ allow us to apply an inverse CDF on a multi-bit quantizer $cal(Q)(2, tilde(x))$ defined in the tilde-domain. 
 Our initial values for $bold(cal(o))_"first"$ can now be defined as the centers of the steps of the transformed quantizer function $cal(Q)(2, x)$.
 These points can be found easily but for the outermost center points whose quantizer steps have a bound $plus.minus infinity$.\
-However, we can still find these two remaining center points by artificially defining the outermost bounds of the quantizer as $frac(1, 2^M dot 4)$ and $frac((2^M dot 4)-1, 2^M dot 4)$ in the tilde-domain and also apply the inverse CDF to them. 
+However, we can still find these two remaining center points by artificially defining the outermost bounds of the quantizer as $frac(1, 2^(2 dot M))$ and $frac((2^(2 dot M))-1, 2^(2 dot M))$ in the tilde-domain and also apply the inverse CDF to them.
 
 #scale(x: 90%, y: 90%)[
 #figure(
@@ -247,33 +270,46 @@ We can also use a simulation here to check the convergence of the distribution $
 #figure(
   grid(
     columns: (2),
-    figure(
+    [#figure(
-      image("./../graphics/plots/bach/stability/frame_1.png")
+      image("./../graphics/plots/bach/stability/frame_1.png"),
-    ),
+      //caption: [Iteration 1]
-    figure(
+    )
+    #v(-2em)
+    Iteration 1],
+    [#figure(
       image("./../graphics/plots/bach/stability/frame_25.png")
-    ),
+    )
+    #v(-2em)
+    Iteration 25],
   ),
   caption: [Probability distributions for the first and 25th iteration of the center point approximation method]
 )<fig:bach_stability>
 
-Comparing the distributions in fig:bach_stability, we can see that besides a closer arrangement the overall shape of the probability distribution $Z$ converges to a Gaussian Mixture representing the original estimated distribution $Z$ through @eq:z_dist_def through smaller normal distributions. 
+Comparing the distributions in @fig:bach_stability, we can see that besides a closer arrangement the overall shape of the probability distribution $Z$ converges to a stable distribution representing the original estimated distribution $Z$ through @eq:z_dist_def through smaller normal distributions. 
 
 The output of @alg:bach_1 is the vector of optimal weights $bold(h)_"opt"$.
 $bold(h)_"opt"$ can now be used to complete the enrollment phase and quantize the values $bold(z)_"opt"$.
 
-To perform reconstruction, we can construct the same linear combination used during enrollment with the found helper-data and the new PUF readout measurements.
+To perform reconstruction, we can calculate the same linear combination used during enrollment with the generated helper-data and the new PUF readout measurements.
+We can lower the computational complexity of this approach by using the assumption that $X$ are i.i.d.. 
+The end result of $bold(cal(o))$ can be calculated once for a specific device series and saved in the ROM of. 
+During enrollment, only the vector $bold(h)_"opt"$ has to be calculated.
+
+=== Impact of helper-data volume and amount of addends
+
+The amount of helper data is directly linked to the symbol bit width $M$ and the amount of addends $N$ used in the linear combination.
+Because we can set the first helper data bit $h_1$ of a linear combination to $1$ to omit the random choice, the resulting extracted bit to helper data bit ratio $cal(r)$ can be defined as $cal(r) = frac(M, N-1)$, whose equation is similar tot he one we used in the @smhdt analysis.
 
 == Experiments 
-To test our implementation of BACH using the prior introduced center point approximation we conducted a similar experiment as in @sect:smhd_experiments.
+To test our implementation of @bach using the prior introduced center point approximation we conducted a similar experiment as in @sect:smhd_experiments.
-However, we have omitted the analysis over different temperatures for the enrollment and reconstruction phase here, as the behaviour of BACH corresponds to that of @smhdt in this matter.
+However, we have omitted the analysis over different temperatures for the enrollment and reconstruction phase here, as the behaviour of @bach corresponds to that of @smhdt in this matter.
 As in the S-Metric analysis, the resulting dataset consists of the bit error rates of various configurations with quantization symbol widths of up to $4$ bits evaluated with up to $10$ addends for the linear combinations.  
 
 == Results & Discussion 
 
-We can now compare the #glspl("ber") of different BACH configurations.
+We can now compare the #glspl("ber") of different @bach configurations.
 
-#figure(
+/*#figure(
   table(
     columns: (9),
     align: center + horizon, 
@@ -284,19 +320,120 @@ We can now compare the #glspl("ber") of different BACH configurations.
     [$M=3$], [$0.07$], [$0.114$], [$0.05$], [$0.15$], [$0.2$], [$0.26$], [$0.26$], [$0.31$],
     [$M=4$], [$0.13$], [$0.09$], [$0.18$], [$0.22$], [$0.26$], [$0.31$], [$0.32$],[$0.35$]
   ),
-  caption: [#glspl("ber") of different BACH configurations]
+  caption: [#glspl("ber") of different @bach configurations]
+)<tab:BACH_performance>*/
+
+
+#figure(
+  kind: table,
+  tablex(
+    columns: 9,
+    align: center + horizon,
+    inset: 7pt,
+    // Color code the table like a heat map
+    
+   map-cells: cell => {
+  if cell.x > 0 and cell.y > 0 {
+    cell.content = {
+      let value = float(cell.content.text)
+      let text-color = if value >= 0.3 {
+        red.lighten(15%)
+      } else if value >= 0.2 {
+        red.lighten(30%)
+      } else if value >= 0.15 {
+        orange.darken(10%)
+      } else if value >= 0.1 {
+        yellow.darken(13%)      } else if value >= 0.08 {
+        yellow
+      } else if value >= 0.06 {
+        olive
+      } else if value >= 0.04 {
+        green.lighten(10%)
+      } else if value >= 0.02 {
+        green
+      } else {
+        green.darken(10%)
+      }
+      cell.fill = text-color
+      strong(cell.content)
+    }
+  }
+  cell
+},
+
+    [*BER*],[N=2],[N=3],[N=4],[N=5], [N=6], [$N=7$], [$N=8$], [$N=9$],
+    [$M=1$], [0.01], [0.01], [0.012], [0.018], [0.044], [0.05], [0.06], [0.07],
+    [$M=2$], [0.03], [0.05], [0.02], [0.078], [0.107], [0.114], [0.143], [0.138],
+    [$M=3$], [0.07], [0.114], [0.05], [0.15], [0.2], [0.26], [0.26], [0.31],
+    [$M=4$], [0.13], [0.09], [0.18], [0.22], [0.26], [0.31], [0.32],[0.35],
+    [$M=5$], [0.29], [0.21], [0.37], [0.31], [0.23], [0.23], [0.19], [0.15],
+    [$M=6$], [0.15], [0.33], [0.15], [0.25], [0.21], [0.23], [0.19], [0.14]
+    
+  ),
+  caption: [#glspl("ber") of different @bach configurations]
 )<tab:BACH_performance>
 
+@tab:BACH_performance shows the #glspl("ber") of @bach configurations with $N$ addends and extracting $M$ bits out of one input value $z$.
+The first interesting property we can observe, is the caveat @bach produces for the first three bit combinations $M = 1, 2 "and" 3$ at around $N = 3$ and $N = 4$. 
+At these points, the @ber experiences a drop followed by a steady rise again for higher numbers of $N$. 
+//This observation could be explained through the fact that the higher $N$ is chosen, the shorter the resulting key, since $N$ divides out values available for quantization by $N$. 
+If $M$ is generally chosen higher, @bach seems to return unstable results, halving the @ber as $N$ reaches $9$ for $M=5$ but showing no real improvement for various addends if $M=6$.
 
-@tab:BACH_performance shows the #glspl("ber") of BACH configurations with $N$ addends and extracting $M$ bits out of one input value $z$.
+We can also compare the performance of @bach using the center point approximation approach with the #glspl("ber") of higher order bit quantizations that don't use any helper data.
-The first interesting property we can observe, is the caveat BACH produces for the first three bit combinations $M = 1, 2 "and" 3$ at around $N = 3$ and $N = 4$. 
-At these points the @ber experiences a drop followed by a steady rise again for higher numbers of $N$. 
-This observation could be explained through the fact that the higher $N$ is chosen, the shorter the resulting key, since $N$ divides out values available for quantization by $N$. 
 
-=== Impact of helper-data volume and amount of addends
+#figure(
+  table(
+    columns: 7,
 
-Contrary to @smhdt, the amount of helper data is directly linked to the amount of available input data provided by the @puf readout. 
+    [*M*], [$1$], [$2$], [$3$], [$4$], [$5$], [$6$],
-In our experiments, this means we will always generate $800$ helper data bits, since our input data consists of $800$ ring-oscillator frequency differences. 
+    [*BER*], [$0.013$], [$0.02$], [$0.04$], [$0.07$], [$0.11$], [$0.16$]
+  ),
+  caption: [#glspl("ber") for higher order bit quantization without helper data ]
+)<tab:no_hd>
 
-If we now take into account, that we divide our input set by $N$ addends to receive values available for quantization and are then able to yield $M$ bits per available value due to our higher-bit quantization, we can define the extracted-bit to helper-data bits ratio as
+Unfortunately, the comparison of #glspl("ber") of @tab:no_hd[Tables] and @tab:BACH_performance[] shows that our current realization of @bach does either ties the @ber in @tab:no_hd or is worse.
-$cal(r) = lr(frac(frac(n dot M, N), 800)mid(|))_(n=800) = frac(M, N)$, whose equation is similar to the one we used in the @smhdt analysis.
+Let's find out why this happens.
+
+==== Justification of the original idea
+
+If we take a step back and look at the performance of the optimized single-bit sign-based quantization process of @sect:1-bit-opt, we can compare the following #glspl("ber"):
+
+#figure(
+  table(
+    columns: 2,
+    [*No helper data*], [$0.013$],
+    [*With helper data using greatest distance*],[$0.00052$],
+    [*With helper data using center point approximation*], [$0.01$]
+
+  ), 
+  caption: [Comparison of #glspl("ber") for the single-bit quantization process with and without helper data]
+)<tab:comparison_justification>
+
+As we can see in @tab:comparison_justification, generating the helper data based on the original idea where @eq:optimization is used improves the @ber of the single-bit quantization by approx. $96%$.
+The probability distributions $Z$ of the two different realizations of @bach -- namely the distance maximization strategy and the center point approximation -- give an indication of this discrepancy: 
+
+#figure(
+grid(
+  columns: (2),
+  [#figure(
+    image("../graphics/plots/bach/compare/bad.png")
+  )
+  #v(-2em)
+  Center point approximation],
+  [#figure(
+    image("../graphics/plots/bach/compare/good.png")
+  )
+  #v(-2em)
+  Distance maximization],
+),
+  caption: [Comparison of the histograms of the different strategies to obtain the optimal weights for the single-bit case]
+)<fig:compar_2_bach>
+
+@fig:compar_2_bach shows the two different probability distributions. 
+We can observe that using a vector of optimal points $bold(cal(o))$ results in a more narrow distribution for $Z$ than just maximizing the linear combination to be as far away from $x=0$ as possible. 
+This difference in the shape of both distributions seem to be the main contributor to the fact that the optimization using center point approximation yields no improvement for the quantization process. 
+Unfortunately, we were not able define an algorithm translating this idea to a higher order bit quantization for which the resulting probability distribution $Z$ converges.
+
+Taking a look at the unstable probability distributions issued by the bound distance maximization strategy in @fig:bach_instability, we can get an idea of what kind of distribution a @bach algorithm should achieve. 
+While the inner parts of the distributions do not overlap with each other like in the stable iterations shown in @fig:bach_stability, the outermost values of these distributions resemble the shape of what we achieved using the distance maximization for a single-bit optimization.
+These two properties could -- if the distribution converges -- result in far better #glspl("ber") for higher order bit quantization, as the comparison in @tab:comparison_justification indicates.

content/SMHD.typ

@@ -310,7 +310,11 @@ At $s=6$ metrics, the biggest metric offset we encounter is $phi = 1/16$ at $i =
 This biggest (or maximum) offset is of particular interest to us, as it tells us how far we deviate from the original quantizer used during enrollment. 
 The maximum offset for a 2-bit configuration $phi$ is $1/16$ and we only introduce smaller offsets in between if we use a higher even number of metrics.
 
-More formally, we can define the maximum metric offset for an even number of metrics as follows: 
+More formally, we can define the maximum metric offset as follows: 
+
+$ phi_"max" = frac(floor(frac(S,2)), 2^M dot S dot 2) $
+
+/*More formally, we can define the maximum metric offset for an even number of metrics as follows: 
 $ phi_("max,even") = frac(frac(S,2), 2^M dot S dot 2) = frac(1, 2^M dot 4) $<eq:max_offset_even>
 
 Here, we multiply $phi$ from @eq:offset by the maximum metric index $i_"max" = S/2$.
@@ -322,8 +326,9 @@ $
 phi_"max,odd" &= frac(frac(S-1, 2), 2^n dot S dot 2)\
 &= lr(frac(S-1, 2^M dot S dot 4)mid(|))_(M=2, S=3) = 1/24
 $
-
+*/
-It is important to note, that $phi_"max,odd"$, unlike $phi_"max,even"$, is dependent on the parameter $S$ as we can see in @tb:odd_offsets.
+//It is important to note, that $phi_"max,odd"$, unlike $phi_"max,even"$, is dependent on the parameter $S$ as we can see in @tb:odd_offsets.
+It is important to note, that $phi_"max"$ is dependent on the parameter $S$ if $S$ is an odd number.
 
 #figure(
   table(
@@ -336,11 +341,11 @@ It is important to note, that $phi_"max,odd"$, unlike $phi_"max,even"$, is depen
   caption: [2-bit maximum offsets, odd]
 )<tb:odd_offsets>
 
-The higher $S$ is chosen, the closer we approximate $phi_"max,even"$ as shown in @eq:offset_limes. 
+The higher $S$ is chosen, the closer we approximate $phi_"max"$ for even choices of $S$, as shown in @eq:offset_limes. 
 This means, while also keeping the original quantizer during the reconstruction phase, the maximum offset for an odd number of metrics will always be smaller than for an even number.
 
 $
-lim_(S arrow.r infinity) phi_"max,odd" &= frac(S-1, 2^M dot S dot 4) #<eq:offset_limes>\
+lim_(S arrow.r infinity) phi_"max,odd" &= frac(floor(frac(S,2)), 2^M dot S dot 2) =  frac(S-1, 2^M dot S dot 4) #<eq:offset_limes>\
 &= frac(1, 2^M dot 4) = phi_"max,even" 
 $
 
@@ -365,21 +370,25 @@ Furthermore, the transformation into the Tilde-Domain could also be performed us
 == Experiments<sect:smhd_experiments>
 
 We tested the implementation of @sect:smhd_implementation with the dataset of @dataset.
-The dataset contains counts of positives edges of a toggle flip flop at a set evaluation time $D$. Based on the count and the evaluation time, the frequency of a ring oscillator can be calculated using: $f = 2 dot frac(k, D)$. 
+The dataset contains counts of positives edges of a ring oscillator at a set evaluation time $D$. Based on the count and the evaluation time, the frequency of a ring oscillator can be calculated using: $f = 2 dot frac(k, D)$. 
 Because we want to analyze the performance of the S-Metric method over different temperatures, both during enrollment and reconstruction, we are limited to the experimental measurements of @dataset which varied the temperature during the FPGA operation. 
-We will have measurements of $50$ FPGA boards available with $1600$ and $1696$ ring oscillators each. To obtain the values to be processed, we subtract them in pairs, yielding $800$ and $848$ ring oscillator frequency differences _df_.\ 
+We will have measurements of $50$ FPGA boards available with $1600$ and $1696$ ring oscillators each.
+The two measurement sets are obtained from different slices of the FPGA board where the only difference to note is the number of ring oscillators available.
+To obtain the values to be processed, we subtract them in pairs, yielding $800$ and $848$ ring oscillator frequency differences _df_.\ 
 Because we can assume that the frequencies _f_ are i.i.d., the difference _df_ can also be assumed to be i.i.d.
 To apply the values _df_ to our implementation of the S-Metric method, we will first transform them into the Tilde-Domain using an inverse CDF, resulting in uniform distributed values $tilde(x)$.
 Our resulting dataset consists of #glspl("ber") for quantization symbol widths of up to $6 "bits"$ evaluated with generated helper-data from up to $100 "metrics"$.
+In the following section, we will often set the maximum number of metrics to be $S=100$.
+This choice refers to the asymptotic behaviour of the @ber and can be equated with the choice $S arrow infinity$.
 //We chose not to perform simulations for bit widths higher than $6 "bits"$, as we will see later that we have already reached a bit error rate of approx. $10%$ for these configurations.
-
+#pagebreak()
 === Results & Discussion
 
 The bit error rate of different S-Metric configurations for naive labelling can be seen in @fig:global_errorrates.
 For this analysis, enrollment and reconstruction were both performed at room temperature. //and the quantizer was naively labelled. 
 
 #figure(
-  image("../graphics/25_25_all_error_rates.svg", width: 95%),
+  image("../graphics/25_25_all_error_rates_fixed.svg", width: 90%),
   caption: [Bit error rates for same-temperature execution. Here we can already observe the asymptotic #glspl("ber") for higher metric numbers. The error rate is scaled logarithmically here.]
 )<fig:global_errorrates>
 
@@ -398,7 +407,7 @@ This tendency can also be shown through @fig:errorrates_changerate.
 Here, we calculated the quotient of the bit error rate using one metric and 100 metrics.
 From $M >= 6$ onwards, $(op("BER")(1, 2^M)) / (op("BER")(100, 2^M))$ approaches $~1$, which means, no real improvement is possible anymore through the S-Metric method.
 
-==== Helper data volume impact
+==== Impact of helper data size
 
 The amount of helper data bits required by @smhdt is defined as a function of the number of metrics as $log_2(S)$.
 The overall extracted-bits to helper-data-bits ratio can be defined here as $cal(r) = frac(M, log_2(S))$
@@ -409,6 +418,7 @@ The overall extracted-bits to helper-data-bits ratio can be defined here as $cal
       inset: 7pt,
       align: center + horizon,
       [$bold(M)$], [$1$], [$2$], [$3$], [$4$], [$5$], [$6$],
+      [$bold(S)$], [$2$], [$4$], [$8$], [$16$], [$32$], [$64$],
       [*@ber*], [$0.012$], [$0.9 dot 10^(-4)$], [$0.002$], [$0.025$], [$0.857$], [$0.148$], 
     ),
     caption: [S-Metric performance with same bit-to-metric ratios]

content/conclusion.typ

@@ -1,17 +1,35 @@
-= Conclusion
+#import "@preview/glossarium:0.4.1": * 
 
-During the course of this work, we took a look at two distinct helper-data algorithms: the S-Metric Helper Data Method and the newly presented method of optimization through Boundary Adaptive Clustering with helper-data. 
+= Comparison of @smhdt and @bach
+
+During the course of this work, we took a look at two distinct helper-data algorithms: the S-Metric Helper Data method and the newly presented method of optimization through Boundary Adaptive Clustering with helper-data. 
 
 The S-Metric method will always outperform BACH considering the amount of helper data needed for operation. 
 This comes from the nature of S-Metric quickly approaching an optimal @ber for a certain bit width and not improving any further for higher amounts of metrics. 
-$
+
-cal(r)_"SMHD" = frac(800 * M, log_2(S))\
-cal(r)_"BACH" = frac(M, N)
-$
 Comparing both formulas for the extracted-bits to helper-data-bits ratio for both methods we can quickly see that S-Metric will always yield more extracted bits per helper-data bit than BACH. 
 
-Considering @ber[BERs], S-Metric does outperform BACH for lower bit values.
+Considering #glspl("ber"), S-Metric does outperform BACH for smaller symbol widths.
-But while the error rate for higher order quantization rises exponentially for higher-order bit quantizations, the @ber[BERs] of BACH do seem to rise rather linear than exponentially for higher-order bit quantizations. 
+But while the error rate for higher order quantization rises exponentially for higher-order bit quantizations, the #glspl("ber") of BACH do seem to rise rather linear than exponentially for higher-order bit quantizations. 
 This behaviour might be attributed to the general procedure of shaping the input values for the quantizer in such a way that they are clustered around the center of a quantizer step, which is a property that carries on for higher order bit quantizations.
 
-Notiz: die Simulation der BERs von BACH an dieser stelle unterstützt die Behauptung die hier steht, aber der 250 Kerne rechner ist tatsächlich noch sehr lange mit der kalkulation beschäftigt. Das wird aber definitiv noch angehängt
+
+We can now compare both the S-Metric Helper Data method and the newly presented method of optimization through Boundary Adaptive Clustering with Helper data based on the @ber and the amount of helper data bits, more specifically the extracted bit to helper data bit ratio $cal(r)$.
+The ratios $cal(r)$ for both methods are defined as: 
+$
+cal(r)_"SMHD" = frac(M, log_2(S))\
+cal(r)_"BACH" = frac(M, N-1)
+$
+
+A good outline to compare both performances of @bach and @smhdt is if $cal(r) = 1$ for varying values of $M$. 
+
+#figure(
+  table(
+    columns: 7,
+
+    [*M*], [$1$], [$2$], [$3$], [$4$], [$5$], [$6$],
+    [*@ber @smhdt*], [$8 dot 10^(-6)$], [$4 dot 10^(-5)$], [$1 dot 10^(-3)$], [$0.02$], [$0.08$], [$0.15$],
+    [*@ber @bach*], [$0.09$], [$0.05$], [$0.05$], [$0.22$], [$0.23$], [$0.23$]
+  ),
+  caption: [#glspl("ber") for @bach and @smhdt configurations that equal the bit width of the quantized symbol and the amount of helper data bits]
+)

content/introduction.typ

@@ -3,7 +3,7 @@
 = Introduction
 
 In the field of cryptography, @puf devices are a popular tool for key generation and storage @PUFIntro @PUFIntro2.
-In general, a @puf describes a kind of circuit that issues due to minimal deviations in the manufacturing process slightly different behaviours during operation. 
+In general, a @puf refers to a type of circuit that exhibits slightly different behaviors during operation due to minor variations in the manufacturing process.
 Since the behaviour of one @puf device is now only reproducible on itself and not on a device of the same type with the same manufacturing process, it can be used for secure key generation and/or storage.\
 
 To improve the reliability of the keys generated and stored using the @puf, various #glspl("hda") have been introduced. 
@@ -60,6 +60,9 @@ $ cal(Q)(S,M) , $<eq-1>
 
 where $S$ determines the number of metrics and $M$ the bit width of the symbols.
 The corresponding metric is defined through the lower case $s$, the bit symbol through the lower case $m$.
+To compare both @smhdt and @bach, we will use a ratio $cal(r) = frac("Extracted bits", "Helper data bits")$.
+This ratio gives us an idea how many helper data bits were used to obtain a quantized symbol. 
+$cal(r)$ is smaller than $1$ if the amount of helper data bits per quantized symbol is bigger than the symbol bit width itself and bigger than $1$ otherwise.
 
 === Tilde Domain<tilde-domain>
 
@@ -68,7 +71,7 @@ As also described in @smhd, we will use a @cdf to transform the real PUF values
 This transformation can be performed using the function $xi = tilde(x)$. The key property of this transformation is the resulting uniform distribution of $x$. 
 
 Considering a normal distribution, the CDF is defined as 
-$ xi(frac(x - mu, sigma)) = frac(1, 2)[1 + op("erf")(frac(x - mu, sigma sqrt(2)))] $
+$ xi(frac(x - mu, sigma)) = frac(1, 2)[1 + op("erf")(frac(x - mu, sigma sqrt(2)))]. $
 
 ==== #gls("ecdf", display: "Empirical cumulative distribution function (eCDF)")
 

content/outlook.typ

@@ -1,12 +1,26 @@
-= Outlook
+= Conclusion and Outlook
 
-Upon the findings of this work, further topics might be investigated in the future. 
+During the course of this work, we took a closer look at an already introduced @hda, @smhdt and provided a concrete realization.
+Our experiments showed that after a certain point, using more metrics $S$ won't improve the @ber any further as they behave asymptotically for $S arrow infinity$.
+Furthermore, we concluded that for higher choices of the symbol width $M$, @smhdt will not be able to improve on the @ber, as the initial error is too high.
+An interesting addition to our analysis provided the improvement of Gray-coded labelling for the quantizer as this resulted in an improvement of $approx 30%$. 
 
-Generally, the performances of both helper-data algorithms might be tested on larger datasets.
+Going on, we introduced the idea of a new @hda which we called Boundary Adaptive Clustering with Helper data @bach. 
+Here we aimed to utilize the idea of moving our initial @puf measurement values away from the quantizer bound to reduce the @ber using weighted linear combinations of our input values. 
+Although this method posed promising results for a sign-based quantization yielding an improvement of $approx 96%$ in our testing, finding a good approach to generalize this concept turned out to be difficult. 
+The first issue was the lack of an analytical description of the probability distribution resulting from the linear combinations. 
+We accounted for that by using an algorithm that alternates between defining the quantizing bounds using an @ecdf and optimizing the weights for the linear combinations based on the found bounds.
+The loose definition of @eq:optimization to find an ideal linear combination which maximizes the distance to its nearest quantization bound did not result in a stable probability distribution over various iterations.
+Thus, we proposed a different approach to approximate the linear combination to the centers between the quantizing bounds. 
+This method resulted in a stable probability distribution, but did not provide any meaningful improvements to the @ber in comparison to not using any helper data at all. 
 
-Specifically concerning the BACH method, instead of using only $plus.minus 1$ as weights for the linear combinations, fractional weights could be used instead as they could provide more flexibility for the outcome of the linear combinations. 
+Future investigations of the @bach idea might find a solution to the convergence of the bound distance maximization strategy.
-In the same sense, a more efficient method to find the optimal linear combination might exist.
+Since the vector of bounds $bold(b)$ is updated every iteration of @bach, a limit to the deviation from the previous position of a bound might be set.
+Furthermore, a recursive approach to reach higher order bit quantization inputs might also result in a converging distribution.
+If we do not want to give up the approach using a vector of optimal points $bold(cal(o))$ as in the center point approximation, a way may be found to increase the distance between all optimal points $bold(cal(o))$ to achieve a better separation for the results of the linear combinations in every quantizer bin.
 
-During the iterative process of the center point approximation in BACH, a way may be found to increase the distance between all optimal points $bold(cal(o))$ to achieve a better separation for the results of the linear combinations in every quantizer bin.
+If a converging realization of @bach is found, using fractional weights instead of $plus.minus 1$ could provide more flexibility for the outcome of the linear combinations. 
 
+Ultimately, we can build on this in the future and provide a complete key storage system using @bach or @smhdt to improve the quantization process. 
 
+But in the end, the real quantizers were the friends we made along the way. 

data/errorrates/bach/errorrates_bonus.csv

@@ -1,17 +1,17 @@
 addends,bit,errorrate
-10,5,0.2965336
+2,5,0.2965336
-10,5,0.213798947368421
+3,5,0.213798947368421
-10,5,0.37411818181818185
+4,5,0.37411818181818185
-10,5,0.312252030075188
+5,5,0.312252030075188
-10,5,0.23020799999999994
+6,5,0.23020799999999994
-10,5,0.23144159999999997
+7,5,0.23144159999999997
-10,5,0.18691639097744356
+8,5,0.18691639097744356
-10,5,0.14719559999999998
+9,5,0.14719559999999998
-10,6,0.1480327485380117
+2,6,0.1480327485380117
-10,6,0.33373909774436084
+3,6,0.33373909774436084
-10,6,0.14506700000000003
+4,6,0.14506700000000003
-10,6,0.256454375
+5,6,0.256454375
-10,6,0.20765733333333333
+6,6,0.20765733333333333
-10,6,0.2271983709273184
+7,6,0.2271983709273184
-10,6,0.19503741666666666
+8,6,0.19503741666666666
-10,6,0.1496060606060606
+9,6,0.1496060606060606

graphics/plots/temperature/25_5_re.typ

@@ -26,8 +26,8 @@
   plot.plot(size: (10,5),
     x-tick-step: none,
     x-ticks: ((0.04, [2]),(2, [100])),
-    y-label: $"Bit error rate"$,
+    y-label: $op("BER")(S, 2^2)$,
-    x-label: $s$,
+    x-label: $S$,
     y-tick-step: 1,
     x-max: 2,
     //y-ticks : (

graphics/plots/temperature/global_diffs/global_diffs.typ

@@ -27,6 +27,8 @@
   plot.plot(
     y-label: "Bit error rate",
     x-label: "Enrollment, reconstruction temperature",
+    legend: "legend.north",
+    legend-style: (offset: (2.25, 0), stroke: none),
     x-tick-step: none,
     x-ticks: conf,
     y-format: formatter,
@@ -39,9 +41,11 @@
 
   plot.plot(
     y2-label: "Temperature difference",
+    legend: "legend.north",
+    legend-style: (offset: (-2.25, 0), stroke: none),
     y2-tick-step: 10,
     axis-style: "scientific-auto",
     size: (16,6),
-    plot.add(diff, axes: ("x1","y2")),
+    plot.add(diff, axes: ("x1","y2"), label: [Temperature difference]),
   )
 })

graphics/quantizers/bach/sign-based-overlay.typ

@@ -10,7 +10,7 @@
     legend-style: (orientation: ltr, item: (spacing: 0.5)),
     x-tick-step: none,
     x-ticks: ((0, [0]), (100, [0])),
-    y-label: $cal(Q)(1, x), xi(x)$,
+    y-label: $cal(Q)(1, x)$,
     x-label: $x$,
     y-tick-step: none,
     y-ticks: ((0, [0]), (ymax, [1])),

main.typ

@@ -32,7 +32,7 @@
   degree: "Bachelor of Science (B.Sc.)",
   examiner: "Prof. Dr. Georg Sigl",
   supervisor: "M.Sc. Jonas Ruchti",
-  submitted: "22.07.2024",
+  submitted: "02.09.2024",
   doc
 )
 #set page(footer: locate(
@@ -45,10 +45,6 @@
 #include "content/introduction.typ"
 #include "content/SMHD.typ"
 #include "content/BACH.typ"
-//#include "content/state.typ"
-//#include "content/implementation.typ"
-//#include "content/benchmarks.typ"
-#include "content/conclusion.typ"
 #include "content/outlook.typ"
 
 #include "glossary.typ"

pseudocode/bach_1.typ

@@ -6,11 +6,12 @@
   + *lists*: optimal weights $bold(h)_"opt"$
   + $bold(cal(o)) arrow.l bold(cal(o))_"first"$
   + #line-label(<alg:bach_1_1>) *repeat* t times: 
-    + *perform* @alg:best_appr for all input values with $bold(cal(o))$:
+    + *perform* #smallcaps[OptimalWeights($bold(cal(0)), bold(x))$]:
-      + *update* $bold(h)_"opt"$ with returned weights
+      + #line-label(<alg:bach_1_2>) *update* $bold(h)_"opt"$ with returned weights
       + $bold(z)_"opt" arrow.l$ all returned linear combinations 
-    + #line-label(<alg:bach_1_2>) *sort* $bold(z)_"opt"$ in ascending order
+    + *define* new quantizer $cal(Q)^*$ using the @ecdf based on $bold(z)_"opt"$:
-    + #line-label(<alg:bach_1_3>) *define* new quantizer $cal(Q)^*$ using the @ecdf based on $bold(z)_"opt"$
+      + *sort* $bold(z)_"opt"$ in ascending order
-    + #line-label(<alg:bach_1_4>) *update* $bold(cal(o))$ with newly found quantizer step centers
+      + $cal(Q)^* arrow.l $ use @eq:ecdf_inverse with quantizer bounds in the tilde domain
+    + #line-label(<alg:bach_1_3>)  *update* $bold(cal(o))$ with newly found quantizer step centers
   + *return* $bold(h)_"opt"$ 
 ]

pseudocode/bach_find_best_appr.typ

@@ -1,6 +1,6 @@
 #import "@preview/lovelace:0.3.0": *
 
-#pseudocode-list(booktabs: true, numbered-title: [Find best approximation])[
+#pseudocode-list(booktabs: true, numbered-title: [OptimalWeights to approximate $bold(cal(o))$])[
   + *inputs*:
     + $bold(y)$ input values for linear combinations
     + $bold(cal(o))$ list of optimal points