\documentclass[main.tex]{subfiles}
\begin{document}

\marginpar{Wednesday\\ 2020-10-7, \\ compiled \\ \today}

We come back to the horizon problem.
[Plot of the comoving Hubble radius \(r_H\) as a function of time]

The problem is solved if there is an early epoch in which \(r_H\) decreases in time, due to accelerated expansion.

After the end of this inflation, the regular FLRW universe's history starts, with the radiation, then matter, then cosmological constant dominated phases.
An accelerated expansion, however, is not enough to solve the horizon problem: what we need is for \emph{every} observable scale, up to the largest ones, was causally connected in the early universe.
In other words, the inflation phase must last \emph{long enough}.

More specifically, our constraint on inflation is that it must start when the Hubble radius was at least as large as it is today.
This can be expressed in terms of the \emph{number of \(e\)-folds}:
%
\begin{align}
N = \log \qty( \frac{a_f}{a _{\text{in}}})
= \int_{t _{\text{in}}}^{t_f} H(t) \dd{t}
\marginnote{Since \(H = \dot{a} / a = \dv{(\log a)}{t}\).}
\,,
\end{align}
%
the ratio of the scale factor at the beginning and at the end of inflation.
% This is a natural measure of time
The number of elapsed \(e\)-folds is a natural measure of time in the epoch of inflation.

We can give the bound \(N \gtrsim 60 \divisionsymbol 70\) in order to solve the horizon problem.
This is a \emph{huge} expansion! Typical atomic scales of \SI{e-15}{m} get stretched to the typical scales of the Solar System, \SI{e11}{m}.

The condition is \(r_H (t _{\text{in}}) \gtrsim r_H (t_0 )\).
We can express this as
%
\begin{align}
\frac{1}{a _{\text{in}} H _{\text{in}}} &\gtrsim \frac{1}{a_0 H_0 }  \\
\frac{a_f}{ a _{\text{in}}} = e^{N} &\gtrsim \frac{H _{\text{in}}}{H_0 } \frac{a_f}{a_0}
\,.
\end{align}
%
\todo[inline]{See on Moodle: paper with the exact computation.}

We want to bring on the left all the quantities in the inflationary epoch.
Recall that \(H^2 \propto \rho \propto a^{-3 (1+ w_i)}\), which we will apply to the inflationary epoch with an equation of state \(w_i < - 1/3\). This means that
%
\begin{align}
\frac{H_i}{H_f} H_f = \qty(\frac{a_i}{a_f})^{-3(1+ w_i) / 2} H_f
\,,
\end{align}
%
so
%
\begin{align}
\frac{a_f}{a_i} \qty(\frac{a_f}{a_i})^{- 3 (1+ w_i) / 2} &\gtrsim
\frac{H_f}{H_0} \frac{a_f}{a_0 } \\
\qty(\frac{a_f}{a_i})^{\frac{-(1 + 3 w_i)}{2}}
&\gtrsim \frac{T_0 }{H_0 } \frac{H_f}{T_f}
\,,
\end{align}
%
where we applied Tolman's law, \(T \sim 1/a\), neglecting the matter dominated phase --- this is a reasonable approximation, we find a similar result to the complete calculation. This yields
%
\begin{align}
N \gtrsim - \frac{2}{1 + 3 w _i} \qty[ \log \frac{T_0 }{H_0 } + \log \frac{H_f}{T_f}]
\,,
\end{align}
%
where \(T_0 = \SI{2.7}{K} \approx \SI{e-13}{GeV}\), while \(H_0 \sim \SI{e-42}{GeV}\) in natural units. Therefore, the first logarithm is of the order \(\sim 67\).
We also need the \emph{pre-heating} temperature and Hubble parameter: \(H_f\) and \(T_f\).
This is model-dependent: it is what gives the theoretical uncertainty.
The dependence, however, is weak: only logarithmic.

With current measurements, we are starting to be able to measure this term as well.
Let us give an estimate for it:
%
\begin{align}
H_f^2 \approx \frac{8 \pi G}{3} \rho _{\text{rad}}
\,,
\end{align}
%
where \(\rho _{\text{rad}} = \frac{\pi^2}{30} g_* T^{4}\). This then yields
%
\begin{align}
H^2_f = \frac{8 \pi G}{3} \frac{\pi^2}{30} g_* T^{4} \sim \frac{T_f^4}{M_P^2}
\,.
\end{align}

There is model dependence here, in \(g_*\)! If we go BDSM (beyond de standard model) it could change.
We are giving a very rough estimate with the Planck mass. This then means \(H_f \sim T_f^2 / M_p\). So,
%
\begin{align}
\log \qty( \frac{H_f}{T_f}) \approx \log \frac{T_f}{M_p}
\,.
\end{align}

Typically, models predict
%
\begin{align}
\num{e-5} < \frac{T_f}{M_p} < 1
\,,
\end{align}
%
but this is not set in stone, we could have different predictions as well.

Now, let us assume that \(w_i \sim -1\), something like a cosmological constant. Then, the prefactor is of the order \(1\), so the bound is \(N \gtrsim 60 \divisionsymbol 70\) as was mentioned before.

We now discuss the causal structure of the FLRW metric:
%
\begin{align}
\dd{s^2} = - \dd{t^2} + a^2(t) \qty[ \frac{ \dd{r^2}}{1 - kr^2} + r^2 \dd{\Omega^2}]
\,.
\end{align}

Let us express this in different coordinates: we introduce \(\chi \), so that
%
\begin{align}
r = S_k (\chi ) = \begin{cases}
    \sinh \chi & k = -1  \\
    \chi & k = 0 \\
    \sin \chi & k = +1
\end{cases}
\,.
\end{align}

This allows the term \(\dd{r^2} / (1 - kr^2)\) to become simply \(\dd{\chi^2}\).

Also, we introduce conformal time: \(\dd{\eta } = \dd{t} / a(t)\), so that the metric becomes
%
\begin{align}
\dd{s^2} = a^2(\eta ) \qty[- \dd{ \eta^2} + \dd{\chi^2} + S_k^2 (\chi ) \dd{\Omega^2}]
\,.
\end{align}

The meaning of \(\chi \) is still a comoving distance.
However, the interesting thing is that this metric is conformally related to (``is a time-dependent rescaling of'') the Minkowski metric (if we consider radial motion, at least), we say that it is \emph{conformally flat}.

In these coordinates, light propagates at \SI{45}{\degree} in the (\(\eta \), \(\chi \)) plane.

Then, we can draw a diagram for the horizon problem in these coordinates: the Big Bang singularity looks like a straight line at constant \(\eta \).
The last-scattering surface is also a straight line at constant \(\eta \).
We can then draw a past light-cone from a point in the last-scattering surface. Inflation pushes the BB surface back in conformal time, so that light has more time to propagate and light cones will intersect.

\begin{claim}
The conformal time at the end of inflation looks like \(\eta \propto 2 / (1 + 3 w) a^{2 / (1 + 3w)} H_*^{-1}\), where \(H_*\) is the Hubble parameter at some reference time.
\end{claim}

\begin{proof}
Let us again make use of the fact that
%
\begin{align}
\dd{\eta } = - \frac{ \dd{z}}{a_0 H(z)}
\,.
\end{align}

Here \(a_0 \) is usually taken to mean ``now'', however the analysis which follows does not really depend on that fact. Then, the conformal time reads
%
\begin{align}
\eta &= \int_0^{\eta} \dd{\widetilde{\eta}}
= \int_{z}^{\infty } \frac{ \dd{\widetilde{z}}}{a_0 H(\widetilde{z})}
\marginnote{Switched the integration margins: \([0, \eta ]\) corresponds to \((\infty, z]\).}
 \\
&= \frac{1}{a_0 H_0 } \int_{z}^{\infty } \frac{ \dd{\widetilde{z}}}{E(\widetilde{z})}
\,.
\end{align}

If we need to account for different fluids the integral cannot be done analytically, so we only account for one: the expression for the \(E\) function simplifies as
%
\begin{align}
E(z) = \sqrt{\sum _{i} \Omega_{0, i} (1 + z)^{3 + 3 w_i}} = \sqrt{(1 + z)^{3 + 3w}}
\,
\end{align}
%
for a single component, with \(\Omega_0 = 1\) and equation of state \(w\). Then, the integral reads
%
\begin{align}
\eta &= \frac{1}{a_0 H_0 } \int_{z}^{\infty } (1 + \widetilde{z})^{-(3 + 3w) / 2} \dd{\widetilde{z}}  \\
&= \frac{1}{a_0 H_0 } \qty(- \frac{1 + 3w}{2})^{-1} \qty[(1 + \widetilde{z})^{-(1+3w) /2}]_{\widetilde{z} = z}^{\widetilde{z} = \infty }  \\
&= \frac{1}{a_0 H_0 } \frac{2}{(1 + 3w)} (1 + z)^{-(1+ 3w) / 2}  \\
&= \frac{2}{(1 + 3w)H_0 } a^{- (1+3w) / 2} a_0^{-1 - (1+ 3w) /2}  \\
&\propto \frac{2}{(1 + 3w)H_0 } a^{- (1+3w) / 2}
\,.
\end{align}

This manipulation only works as long as \(w > - 1/3\): otherwise, the integral diverges.
\end{proof}
% So, if \(w < - 1/3\), we are good.

% \todo[inline]{We can only detect correlations in the CMB up to the quadrupole, since the dipole is correlated with the Earth's motion\dots Roughly, this means that we can only see correlations on the scale of \(\sim r_H\), corresponding to \SI{90}{\degree} separation, instead of being able to see them on the scale of \SI{180}{\degree}. }

\subsection{Flatness problem}

Now, we move to the flatness problem.
The HBB model is not intrinsically flawed, however the shortcomings we are discussing tell us that the initial conditions which would be required in order to yield the current universe would be very specific.

We should set initial conditions which are homogeneous and isotropic, with very specific small fluctuations. Inflation provides a dynamical solution to these problems, which is an attractor towards these initial conditions.\footnote{See \textcite[]{hossenfelderScreamsExplanationFinetuning2019} for a critical discussion of this fine-tuning problem.}

The first Friedmann equation reads
%
\begin{align}
H^2=  \frac{8 \pi G}{3} \rho - \frac{k}{a^2}
\,,
\end{align}
%
which we can express through \(\Omega = \rho / \rho _c\), where \(\rho _c = 3 H^2 / (8 \pi G) \):
%
\begin{align}
\Omega - 1 = \frac{k}{a^2 H^2} = k r_H^2 (t)
\,,
\end{align}
%
so if \(\Omega \) differs from unity even by a small amount, this difference increases with time.

At \SI{95}{\percent} CL, we know that \(\abs{\Omega - 1} = \abs{\Omega _k} < \SI{.4}{\percent}\), so the universe we observe is consistent with flatness.

Specifically, in the Planck epoch we will have
%
\begin{align}
\Omega (t _{\text{Pl}}) - 1 \approx  (\Omega_0 - 1) \times \num{e-60}
\,,
\end{align}
%
so \(\abs{\Omega (t _{\text{Pl}}) - 1} < \num{e-62}\).

\begin{claim}
It can be shown that
%
\begin{align}
\qty(\Omega^{-1} - 1) \rho a^2 = \const = -\frac{3k}{8 \pi G}
\,.
\end{align}
\end{claim}
\begin{proof}
The calculation is as follows:
%
\begin{align}
H^2 &= \frac{8 \pi G}{3} \rho - \frac{k}{a^2}  \\
\rho _c &= \rho - \underbrace{\frac{3 k}{8 \pi G}}_{\const} \frac{1}{a^2}  \\
\rho \bigg( \underbrace{\frac{\rho _c}{\rho }}_{\Omega^{-1}} - 1\bigg) a^2 &= \const
\,.
\end{align}

\end{proof}

For times before the matter-radiation equivalence \(\rho \propto a^{-4}\), so (neglecting the matter component) \(\rho (t) = \rho _{\text{eq}} (a _{\text{eq}} / a)^{4}\). Also, during matter domination up to now (neglecting the cosmological constant)
%
\begin{align}
\rho_0 = \rho _{\text{eq}} \qty(\frac{a _{\text{eq}}}{a_0 })^3
\,,
\end{align}
%
therefore
%
\begin{align}
(\Omega^{-1} -1) \qty(\frac{a _{\text{eq}}}{a})^{4} a^2 \rho _{\text{eq}} \qty(\frac{a_0 }{a _{\text{eq}}})^{3} \frac{1}{\rho _{\text{eq}} a_0^2} &= (\Omega_0^{-1} - 1)
\\
\Omega^{-1} - 1 &= (\Omega_0^{-1} -1) \frac{a^2}{a _{\text{eq}} a_0 } \\
\Omega^{-1} - 1 &= (\Omega_0^{-1} -1) (1 + z _{\text{eq}}) \frac{a^2}{a_0^2}
\,,
\end{align}
%
since \(1 + z _{\text{eq}} = a_0 / a _{\text{eq}}\). Also, we can approximate \(a/a_0 \sim T_0 / T _{\text{Pl}}\) by extending Tolman's law.
Then,
%
\begin{align}
\Omega^{-1} - 1 &= (\Omega_0^{-1} -1) \underbrace{(1 + z _{\text{eq}})}_{\sim \num{e4}} \underbrace{\frac{T_0 ^2}{T _{\text{Pl}}^2}}_{\sim \num{e-64}}
\,.
\end{align}

This proves the relation we wrote earlier. It is an extreme extrapolation to go back to the Planck time, but even if we only went back to Big Bang nucleosynthesis (\(\sim \SI{1}{MeV}\)) we would get
%
\begin{align}
\abs{\Omega (t _{\text{BBN}}) - 1 } < \num{e-18}
\,.
\end{align}

How does inflation solve the problem?
Recall that \(\Omega -1  = k r_H^2\), and inflation is by definition a time in which \(r_H\) decreases.
At the end of inflation, \(\Omega - 1\) is very close to 0, meaning that \(r_H\) is small, but at the start of inflation it could have been relatively far from 1.

Next week we will discuss the proper mechanism of this process.
During an inflationary phase, \(a (t) \approx \exp(Ht)\). So, as long as \(H\) is approximately constant, we have
%
\begin{align}
r_H^2 = \frac{1}{a^2 H^2} \propto \frac{1}{a^2}
\,.
\end{align}

Then, we have
%
\begin{align}
\frac{\abs{\Omega -1}_{t_f}}{\abs{\Omega - 1}_{t_i}} \sim \qty(\frac{a_i}{a_f})^{2} \sim \exp(- 2N)
\,.
\end{align}

This means that, with very broad possible initial conditions, we find \(\Omega -1\) very close to zero at the end of inflation.

A De-Sitter phase is a reference example of a possible inflationary stage.
It would correspond to \(\rho = \const\), \(w = -1\): in general, since the ``curvature energy density'' scales like \(a^{-2}\), curvature becomes negligible.

Note, however, that this is an unrealistic example: it does not include any method for the inflation to end.

\end{document}


\documentclass[a4paper,10pt]{article}
\title{Wilcoxon Signed Ranks test.}
\date{\today}
\author{KEEL non-parametric statistical module}
\begin{document}

\pagestyle{empty}
\maketitle
\thispagestyle{empty}

\section{Detailed results for no-features}

\subsection{Results}

\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|c|c|}
\hline
 VS & $R^{+}$ & $R^{-}$ & Exact P-value & Asymptotic P-value \\ \hline
features & 194.0 & 271.0 & $\geq$ 0.2 & 1\\ \hline
voting & 152.0 & 313.0 & $\geq$ 0.2 & 1\\ \hline
bagging & 233.0 & 263.0 & $\geq$ 0.2 & 1\\ \hline
svm-lin & 280.0 & 216.0 & $\geq$ 0.2 & 0.524198\\ \hline
svm-rbf & 159.0 & 306.0 & $\geq$ 0.2 & 1\\ \hline
knn3 & 159.0 & 306.0 & $\geq$ 0.2 & 1\\ \hline
knn5 & 389.0 & 107.0 & 0.004752 & 0.005556\\ \hline
mlp & 360.0 & 105.0 & 0.007612 & 0.00847\\ \hline

\end{tabular}
\caption{Results obtained by the Wilcoxon test for algorithm no-features}
\end{table}

\subsection{Confidence intervals for Median of diferences}

\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|}
\hline
 $\alpha$=0.90 & Confidence interval & Exact confidence \\ \hline
features & [-0.003427 , 0.001041] & 0.90182\\ \hline
voting & [-0.018906 , 0] & 0.90182\\ \hline
bagging & [-0.01 , 0.007856] & 0.90182\\ \hline
svm-lin & [-0.01249 , 0.03584] & 0.90182\\ \hline
svm-rbf & [-0.025688 , 0.001238] & 0.90182\\ \hline
knn3 & [-0.025688 , 0.001238] & 0.90182\\ \hline
knn5 & [0.008587 , 0.036948] & 0.90182\\ \hline
mlp & [0.007629 , 0.035931] & 0.90182\\ \hline

\end{tabular}
\caption{Confidence intervals for algorithm no-features ($\alpha$=0.90)}
\end{table}
\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|}
\hline
 $\alpha$=0.95 & Confidence interval & Exact confidence \\ \hline
features & [-0.003845 , 0.001525] & 0.9521\\ \hline
voting & [-0.021229 , 0.002776] & 0.9521\\ \hline
bagging & [-0.011777 , 0.009389] & 0.9521\\ \hline
svm-lin & [-0.015173 , 0.044271] & 0.9521\\ \hline
svm-rbf & [-0.027805 , 0.004204] & 0.9521\\ \hline
knn3 & [-0.027805 , 0.004204] & 0.9521\\ \hline
knn5 & [0.006451 , 0.039682] & 0.9521\\ \hline
mlp & [0.004637 , 0.039409] & 0.9521\\ \hline

\end{tabular}
\caption{Confidence intervals for algorithm no-features ($\alpha$=0.95)}
\end{table}

 \clearpage

\section{Detailed results for features}

\subsection{Results}

\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|c|c|}
\hline
 VS & $R^{+}$ & $R^{-}$ & Exact P-value & Asymptotic P-value \\ \hline
no-features & 271.0 & 194.0 & $\geq$ 0.2 & 0.422457\\ \hline
voting & 162.0 & 303.0 & $\geq$ 0.2 & 1\\ \hline
bagging & 219.0 & 246.0 & $\geq$ 0.2 & 1\\ \hline
svm-lin & 280.0 & 216.0 & $\geq$ 0.2 & 0.524198\\ \hline
svm-rbf & 171.0 & 294.0 & $\geq$ 0.2 & 1\\ \hline
knn3 & 171.0 & 294.0 & $\geq$ 0.2 & 1\\ \hline
knn5 & 393.0 & 103.0 & 0.003598 & 0.004354\\ \hline
mlp & 374.0 & 122.0 & 0.012432 & 0.013176\\ \hline

\end{tabular}
\caption{Results obtained by the Wilcoxon test for algorithm features}
\end{table}

\subsection{Confidence intervals for Median of diferences}

\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|}
\hline
 $\alpha$=0.90 & Confidence interval & Exact confidence \\ \hline
no-features & [-0.001041 , 0.003427] & 0.90182\\ \hline
voting & [-0.019587 , 0.002341] & 0.90182\\ \hline
bagging & [-0.009995 , 0.007197] & 0.90182\\ \hline
svm-lin & [-0.012311 , 0.038649] & 0.90182\\ \hline
svm-rbf & [-0.025331 , 0.003499] & 0.90182\\ \hline
knn3 & [-0.025331 , 0.003499] & 0.90182\\ \hline
knn5 & [0.009214 , 0.037489] & 0.90182\\ \hline
mlp & [0.008169 , 0.037251] & 0.90182\\ \hline

\end{tabular}
\caption{Confidence intervals for algorithm features ($\alpha$=0.90)}
\end{table}
\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|}
\hline
 $\alpha$=0.95 & Confidence interval & Exact confidence \\ \hline
no-features & [-0.001525 , 0.003845] & 0.9521\\ \hline
voting & [-0.021 , 0.003998] & 0.9521\\ \hline
bagging & [-0.011579 , 0.009372] & 0.9521\\ \hline
svm-lin & [-0.015417 , 0.045676] & 0.9521\\ \hline
svm-rbf & [-0.027915 , 0.005656] & 0.9521\\ \hline
knn3 & [-0.027915 , 0.005656] & 0.9521\\ \hline
knn5 & [0.006989 , 0.041708] & 0.9521\\ \hline
mlp & [0.004317 , 0.040127] & 0.9521\\ \hline

\end{tabular}
\caption{Confidence intervals for algorithm features ($\alpha$=0.95)}
\end{table}

 \clearpage

\section{Detailed results for voting}

\subsection{Results}

\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|c|c|}
\hline
 VS & $R^{+}$ & $R^{-}$ & Exact P-value & Asymptotic P-value \\ \hline
no-features & 313.0 & 152.0 & 0.1004 & 0.095706\\ \hline
features & 303.0 & 162.0 & 0.15188 & 0.144193\\ \hline
bagging & 348.0 & 148.0 & 0.05024 & 0.048901\\ \hline
svm-lin & 379.0 & 117.0 & 0.009148 & 0.009968\\ \hline
svm-rbf & 195.0 & 270.0 & $\geq$ 0.2 & 1\\ \hline
knn3 & 195.0 & 270.0 & $\geq$ 0.2 & 1\\ \hline
knn5 & 482.0 & 14.0 & 1.0244E-7 & 0.000004\\ \hline
mlp & 490.0 & 6.0 & 1.3038E-8 & 0.000002\\ \hline

\end{tabular}
\caption{Results obtained by the Wilcoxon test for algorithm voting}
\end{table}

\subsection{Confidence intervals for Median of diferences}

\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|}
\hline
 $\alpha$=0.90 & Confidence interval & Exact confidence \\ \hline
no-features & [0 , 0.018906] & 0.90182\\ \hline
features & [-0.002341 , 0.019587] & 0.90182\\ \hline
bagging & [0.001961 , 0.023434] & 0.90182\\ \hline
svm-lin & [0.003494 , 0.038727] & 0.90182\\ \hline
svm-rbf & [-0.007311 , 0.002286] & 0.90182\\ \hline
knn3 & [-0.007311 , 0.002286] & 0.90182\\ \hline
knn5 & [0.022858 , 0.041694] & 0.90182\\ \hline
mlp & [0.022108 , 0.037243] & 0.90182\\ \hline

\end{tabular}
\caption{Confidence intervals for algorithm voting ($\alpha$=0.90)}
\end{table}
\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|}
\hline
 $\alpha$=0.95 & Confidence interval & Exact confidence \\ \hline
no-features & [-0.002776 , 0.021229] & 0.9521\\ \hline
features & [-0.003998 , 0.021] & 0.9521\\ \hline
bagging & [-0.000258 , 0.026104] & 0.9521\\ \hline
svm-lin & [0.002014 , 0.049373] & 0.9521\\ \hline
svm-rbf & [-0.008866 , 0.003289] & 0.9521\\ \hline
knn3 & [-0.008866 , 0.003289] & 0.9521\\ \hline
knn5 & [0.021008 , 0.044465] & 0.9521\\ \hline
mlp & [0.020545 , 0.039383] & 0.9521\\ \hline

\end{tabular}
\caption{Confidence intervals for algorithm voting ($\alpha$=0.95)}
\end{table}

 \clearpage

\section{Detailed results for bagging}

\subsection{Results}

\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|c|c|}
\hline
 VS & $R^{+}$ & $R^{-}$ & Exact P-value & Asymptotic P-value \\ \hline
no-features & 263.0 & 233.0 & $\geq$ 0.2 & 0.761321\\ \hline
features & 246.0 & 219.0 & $\geq$ 0.2 & 0.77338\\ \hline
voting & 148.0 & 348.0 & $\geq$ 0.2 & 1\\ \hline
svm-lin & 248.0 & 248.0 & $\geq$ 0.2 & 0.992182\\ \hline
svm-rbf & 139.0 & 357.0 & $\geq$ 0.2 & 1\\ \hline
knn3 & 139.0 & 357.0 & $\geq$ 0.2 & 1\\ \hline
knn5 & 383.0 & 113.0 & 0.007088 & 0.007923\\ \hline
mlp & 355.0 & 141.0 & 0.03558 & 0.03515\\ \hline

\end{tabular}
\caption{Results obtained by the Wilcoxon test for algorithm bagging}
\end{table}

\subsection{Confidence intervals for Median of diferences}

\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|}
\hline
 $\alpha$=0.90 & Confidence interval & Exact confidence \\ \hline
no-features & [-0.007856 , 0.01] & 0.90182\\ \hline
features & [-0.007197 , 0.009995] & 0.90182\\ \hline
voting & [-0.023434 , -0.001961] & 0.90182\\ \hline
svm-lin & [-0.016785 , 0.029622] & 0.90182\\ \hline
svm-rbf & [-0.027765 , -0.005666] & 0.90182\\ \hline
knn3 & [-0.027765 , -0.005666] & 0.90182\\ \hline
knn5 & [0.008017 , 0.036183] & 0.90182\\ \hline
mlp & [0.003571 , 0.032056] & 0.90182\\ \hline

\end{tabular}
\caption{Confidence intervals for algorithm bagging ($\alpha$=0.90)}
\end{table}
\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|}
\hline
 $\alpha$=0.95 & Confidence interval & Exact confidence \\ \hline
no-features & [-0.009389 , 0.011777] & 0.9521\\ \hline
features & [-0.009372 , 0.011579] & 0.9521\\ \hline
voting & [-0.026104 , 0.000258] & 0.9521\\ \hline
svm-lin & [-0.019752 , 0.035137] & 0.9521\\ \hline
svm-rbf & [-0.03042 , -0.002545] & 0.9521\\ \hline
knn3 & [-0.03042 , -0.002545] & 0.9521\\ \hline
knn5 & [0.006602 , 0.038597] & 0.9521\\ \hline
mlp & [0.001184 , 0.03602] & 0.9521\\ \hline

\end{tabular}
\caption{Confidence intervals for algorithm bagging ($\alpha$=0.95)}
\end{table}

 \clearpage

\section{Detailed results for svm-lin}

\subsection{Results}

\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|c|c|}
\hline
 VS & $R^{+}$ & $R^{-}$ & Exact P-value & Asymptotic P-value \\ \hline
no-features & 216.0 & 280.0 & $\geq$ 0.2 & 1\\ \hline
features & 216.0 & 280.0 & $\geq$ 0.2 & 1\\ \hline
voting & 117.0 & 379.0 & $\geq$ 0.2 & 1\\ \hline
bagging & 248.0 & 248.0 & $\geq$ 0.2 & 0.992182\\ \hline
svm-rbf & 88.5 & 376.5 & $\geq$ 0.2 & 1\\ \hline
knn3 & 88.5 & 376.5 & $\geq$ 0.2 & 1\\ \hline
knn5 & 316.0 & 180.0 & 0.18866 & 0.179478\\ \hline
mlp & 309.0 & 187.0 & $\geq$ 0.2 & 0.228131\\ \hline

\end{tabular}
\caption{Results obtained by the Wilcoxon test for algorithm svm-lin}
\end{table}

\subsection{Confidence intervals for Median of diferences}

\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|}
\hline
 $\alpha$=0.90 & Confidence interval & Exact confidence \\ \hline
no-features & [-0.03584 , 0.01249] & 0.90182\\ \hline
features & [-0.038649 , 0.012311] & 0.90182\\ \hline
voting & [-0.038727 , -0.003494] & 0.90182\\ \hline
bagging & [-0.029622 , 0.016785] & 0.90182\\ \hline
svm-rbf & [-0.045601 , -0.006963] & 0.90182\\ \hline
knn3 & [-0.045601 , -0.006963] & 0.90182\\ \hline
knn5 & [-0.012359 , 0.029786] & 0.90182\\ \hline
mlp & [-0.008037 , 0.02484] & 0.90182\\ \hline

\end{tabular}
\caption{Confidence intervals for algorithm svm-lin ($\alpha$=0.90)}
\end{table}
\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|}
\hline
 $\alpha$=0.95 & Confidence interval & Exact confidence \\ \hline
no-features & [-0.044271 , 0.015173] & 0.9521\\ \hline
features & [-0.045676 , 0.015417] & 0.9521\\ \hline
voting & [-0.049373 , -0.002014] & 0.9521\\ \hline
bagging & [-0.035137 , 0.019752] & 0.9521\\ \hline
svm-rbf & [-0.048474 , -0.005111] & 0.9521\\ \hline
knn3 & [-0.048474 , -0.005111] & 0.9521\\ \hline
knn5 & [-0.029511 , 0.032364] & 0.9521\\ \hline
mlp & [-0.014593 , 0.026545] & 0.9521\\ \hline

\end{tabular}
\caption{Confidence intervals for algorithm svm-lin ($\alpha$=0.95)}
\end{table}

 \clearpage

\section{Detailed results for svm-rbf}

\subsection{Results}

\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|c|c|}
\hline
 VS & $R^{+}$ & $R^{-}$ & Exact P-value & Asymptotic P-value \\ \hline
no-features & 306.0 & 159.0 & 0.13474 & 0.127995\\ \hline
features & 294.0 & 171.0 & $\geq$ 0.2 & 0.202225\\ \hline
voting & 270.0 & 195.0 & $\geq$ 0.2 & 0.434452\\ \hline
bagging & 357.0 & 139.0 & 0.03212 & 0.031887\\ \hline
svm-lin & 376.5 & 88.5 & 0.0022779999999999996 & 0.002957\\ \hline
knn3 & 232.5 & 232.5 & $\geq$ 0.2 & 0.991795\\ \hline
knn5 & 457.0 & 39.0 & 7.006E-6 & 0.00004\\ \hline
mlp & 472.0 & 24.0 & 7.096E-7 & 0.000011\\ \hline

\end{tabular}
\caption{Results obtained by the Wilcoxon test for algorithm svm-rbf}
\end{table}

\subsection{Confidence intervals for Median of diferences}

\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|}
\hline
 $\alpha$=0.90 & Confidence interval & Exact confidence \\ \hline
no-features & [-0.001238 , 0.025688] & 0.90182\\ \hline
features & [-0.003499 , 0.025331] & 0.90182\\ \hline
voting & [-0.002286 , 0.007311] & 0.90182\\ \hline
bagging & [0.005666 , 0.027765] & 0.90182\\ \hline
svm-lin & [0.006963 , 0.045601] & 0.90182\\ \hline
knn3 & [0 , 0] & 0.90182\\ \hline
knn5 & [0.02428 , 0.049381] & 0.90182\\ \hline
mlp & [0.024474 , 0.04485] & 0.90182\\ \hline

\end{tabular}
\caption{Confidence intervals for algorithm svm-rbf ($\alpha$=0.90)}
\end{table}
\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|}
\hline
 $\alpha$=0.95 & Confidence interval & Exact confidence \\ \hline
no-features & [-0.004204 , 0.027805] & 0.9521\\ \hline
features & [-0.005656 , 0.027915] & 0.9521\\ \hline
voting & [-0.003289 , 0.008866] & 0.9521\\ \hline
bagging & [0.002545 , 0.03042] & 0.9521\\ \hline
svm-lin & [0.005111 , 0.048474] & 0.9521\\ \hline
knn3 & [0 , 0] & 0.9521\\ \hline
knn5 & [0.021493 , 0.0517] & 0.9521\\ \hline
mlp & [0.021698 , 0.046523] & 0.9521\\ \hline

\end{tabular}
\caption{Confidence intervals for algorithm svm-rbf ($\alpha$=0.95)}
\end{table}

 \clearpage

\section{Detailed results for knn3}

\subsection{Results}

\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|c|c|}
\hline
 VS & $R^{+}$ & $R^{-}$ & Exact P-value & Asymptotic P-value \\ \hline
no-features & 306.0 & 159.0 & 0.13474 & 0.127995\\ \hline
features & 294.0 & 171.0 & $\geq$ 0.2 & 0.202225\\ \hline
voting & 270.0 & 195.0 & $\geq$ 0.2 & 0.434452\\ \hline
bagging & 357.0 & 139.0 & 0.03212 & 0.031887\\ \hline
svm-lin & 376.5 & 88.5 & 0.0022779999999999996 & 0.002957\\ \hline
svm-rbf & 232.5 & 232.5 & $\geq$ 0.2 & 0.991795\\ \hline
knn5 & 457.0 & 39.0 & 7.006E-6 & 0.00004\\ \hline
mlp & 472.0 & 24.0 & 7.096E-7 & 0.000011\\ \hline

\end{tabular}
\caption{Results obtained by the Wilcoxon test for algorithm knn3}
\end{table}

\subsection{Confidence intervals for Median of diferences}

\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|}
\hline
 $\alpha$=0.90 & Confidence interval & Exact confidence \\ \hline
no-features & [-0.001238 , 0.025688] & 0.90182\\ \hline
features & [-0.003499 , 0.025331] & 0.90182\\ \hline
voting & [-0.002286 , 0.007311] & 0.90182\\ \hline
bagging & [0.005666 , 0.027765] & 0.90182\\ \hline
svm-lin & [0.006963 , 0.045601] & 0.90182\\ \hline
svm-rbf & [0 , 0] & 0.90182\\ \hline
knn5 & [0.02428 , 0.049381] & 0.90182\\ \hline
mlp & [0.024474 , 0.04485] & 0.90182\\ \hline

\end{tabular}
\caption{Confidence intervals for algorithm knn3 ($\alpha$=0.90)}
\end{table}
\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|}
\hline
 $\alpha$=0.95 & Confidence interval & Exact confidence \\ \hline
no-features & [-0.004204 , 0.027805] & 0.9521\\ \hline
features & [-0.005656 , 0.027915] & 0.9521\\ \hline
voting & [-0.003289 , 0.008866] & 0.9521\\ \hline
bagging & [0.002545 , 0.03042] & 0.9521\\ \hline
svm-lin & [0.005111 , 0.048474] & 0.9521\\ \hline
svm-rbf & [0 , 0] & 0.9521\\ \hline
knn5 & [0.021493 , 0.0517] & 0.9521\\ \hline
mlp & [0.021698 , 0.046523] & 0.9521\\ \hline

\end{tabular}
\caption{Confidence intervals for algorithm knn3 ($\alpha$=0.95)}
\end{table}

 \clearpage

\section{Detailed results for knn5}

\subsection{Results}

\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|c|c|}
\hline
 VS & $R^{+}$ & $R^{-}$ & Exact P-value & Asymptotic P-value \\ \hline
no-features & 107.0 & 389.0 & $\geq$ 0.2 & 1\\ \hline
features & 103.0 & 393.0 & $\geq$ 0.2 & 1\\ \hline
voting & 14.0 & 482.0 & $\geq$ 0.2 & 1\\ \hline
bagging & 113.0 & 383.0 & $\geq$ 0.2 & 1\\ \hline
svm-lin & 180.0 & 316.0 & $\geq$ 0.2 & 1\\ \hline
svm-rbf & 39.0 & 457.0 & $\geq$ 0.2 & 1\\ \hline
knn3 & 39.0 & 457.0 & $\geq$ 0.2 & 1\\ \hline
mlp & 167.0 & 298.0 & $\geq$ 0.2 & 1\\ \hline

\end{tabular}
\caption{Results obtained by the Wilcoxon test for algorithm knn5}
\end{table}

\subsection{Confidence intervals for Median of diferences}

\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|}
\hline
 $\alpha$=0.90 & Confidence interval & Exact confidence \\ \hline
no-features & [-0.036948 , -0.008587] & 0.90182\\ \hline
features & [-0.037489 , -0.009214] & 0.90182\\ \hline
voting & [-0.041694 , -0.022858] & 0.90182\\ \hline
bagging & [-0.036183 , -0.008017] & 0.90182\\ \hline
svm-lin & [-0.029786 , 0.012359] & 0.90182\\ \hline
svm-rbf & [-0.049381 , -0.02428] & 0.90182\\ \hline
knn3 & [-0.049381 , -0.02428] & 0.90182\\ \hline
mlp & [-0.01 , 0.000999] & 0.90182\\ \hline

\end{tabular}
\caption{Confidence intervals for algorithm knn5 ($\alpha$=0.90)}
\end{table}
\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|}
\hline
 $\alpha$=0.95 & Confidence interval & Exact confidence \\ \hline
no-features & [-0.039682 , -0.006451] & 0.9521\\ \hline
features & [-0.041708 , -0.006989] & 0.9521\\ \hline
voting & [-0.044465 , -0.021008] & 0.9521\\ \hline
bagging & [-0.038597 , -0.006602] & 0.9521\\ \hline
svm-lin & [-0.032364 , 0.029511] & 0.9521\\ \hline
svm-rbf & [-0.0517 , -0.021493] & 0.9521\\ \hline
knn3 & [-0.0517 , -0.021493] & 0.9521\\ \hline
mlp & [-0.011054 , 0.002555] & 0.9521\\ \hline

\end{tabular}
\caption{Confidence intervals for algorithm knn5 ($\alpha$=0.95)}
\end{table}

 \clearpage

\section{Detailed results for mlp}

\subsection{Results}

\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|c|c|}
\hline
 VS & $R^{+}$ & $R^{-}$ & Exact P-value & Asymptotic P-value \\ \hline
no-features & 105.0 & 360.0 & $\geq$ 0.2 & 1\\ \hline
features & 122.0 & 374.0 & $\geq$ 0.2 & 1\\ \hline
voting & 6.0 & 490.0 & $\geq$ 0.2 & 1\\ \hline
bagging & 141.0 & 355.0 & $\geq$ 0.2 & 1\\ \hline
svm-lin & 187.0 & 309.0 & $\geq$ 0.2 & 1\\ \hline
svm-rbf & 24.0 & 472.0 & $\geq$ 0.2 & 1\\ \hline
knn3 & 24.0 & 472.0 & $\geq$ 0.2 & 1\\ \hline
knn5 & 298.0 & 167.0 & 0.18396 & 0.174619\\ \hline

\end{tabular}
\caption{Results obtained by the Wilcoxon test for algorithm mlp}
\end{table}

\subsection{Confidence intervals for Median of diferences}

\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|}
\hline
 $\alpha$=0.90 & Confidence interval & Exact confidence \\ \hline
no-features & [-0.035931 , -0.007629] & 0.90182\\ \hline
features & [-0.037251 , -0.008169] & 0.90182\\ \hline
voting & [-0.037243 , -0.022108] & 0.90182\\ \hline
bagging & [-0.032056 , -0.003571] & 0.90182\\ \hline
svm-lin & [-0.02484 , 0.008037] & 0.90182\\ \hline
svm-rbf & [-0.04485 , -0.024474] & 0.90182\\ \hline
knn3 & [-0.04485 , -0.024474] & 0.90182\\ \hline
knn5 & [-0.000999 , 0.01] & 0.90182\\ \hline

\end{tabular}
\caption{Confidence intervals for algorithm mlp ($\alpha$=0.90)}
\end{table}
\begin{table}[!htp]
\centering\small
\begin{tabular}{
|c|c|c|}
\hline
 $\alpha$=0.95 & Confidence interval & Exact confidence \\ \hline
no-features & [-0.039409 , -0.004637] & 0.9521\\ \hline
features & [-0.040127 , -0.004317] & 0.9521\\ \hline
voting & [-0.039383 , -0.020545] & 0.9521\\ \hline
bagging & [-0.03602 , -0.001184] & 0.9521\\ \hline
svm-lin & [-0.026545 , 0.014593] & 0.9521\\ \hline
svm-rbf & [-0.046523 , -0.021698] & 0.9521\\ \hline
knn3 & [-0.046523 , -0.021698] & 0.9521\\ \hline
knn5 & [-0.002555 , 0.011054] & 0.9521\\ \hline

\end{tabular}
\caption{Confidence intervals for algorithm mlp ($\alpha$=0.95)}
\end{table}

 \clearpage

\end{document}


\chapter{Introduction}

\section{What is it}
Rob's Audio Processing Toolkit (abbreviated as RAPT) is an open source C++ library for audio signal processing with a focus on musical signals. The lower levels of the library provide the numerical functionality that is relevant in this context (such as basic linear algebra, polynomial manipulation, Fourier transforms, interpolation, etc.). On top of that, a toolkit of audio processing specific algorithms is built. These algorithms are typically the ones, that client code will want to call, although it is also possible to reach down into the lower levels of the basic mathematical number crunching routines.
%For the basic mathematical functionality, a mix of proprietary implementations and wrappers around freely available libraries is used. The audio specific code is mostly original

\section{Copyright and Licensing}
The copyright of the code is owned by the author, Robin Schmidt, and is released under the terms of the GNU General Public License (GPL). Basically, that means, if you want to use it somewhere, you have to open-source your project, too. If you want to use the code in a closed source product, you may contact me for negotiating the terms [...t.b.c]

\section{Design Principles}

\subsection{Type Independence}
Most of the functions and classes are written in a generic way in order to make them applicable to whatever kind of datatype you are dealing with. Technically, that means they are implemented as C++ templates. For example, if you have a class for representing multichannel audio data and that class provides appropriate operators for addition and multiplication (i.e. add/multiply the individual channel data element-wise), you can apply a generic convolution routine that convolves two sequences of your multichannel datatype (assuming they have a compatible number of channels - but these compatibility requirements will depend on the implementation of the \texttt{+} and \texttt{*} operators of your class). You may also want to use convolutions on complex numbers and/or multiprecision datatypes. The genericity of the implementation allows for that. TODO: change example  - explain how to use a ladder filter on generic datatypes

%\subsection{Convenient Integration}
%RAPT should integrate with other software projects as smoothly as possible. That's why it strives for using the C++ standard library as much as possible for representing commonly used datatypes such as complex numbers or vectors. Instead of defining it's own classes for representing these things, \texttt{std:complex} and \texttt{std::vector} are used. For matrices, the \texttt{boost::matrix} implementation is used. Prior to implementing this library, I had a habit of reinventing the wheel which was unnecessary additional work and complicates the integration with other code, since proprietary data representations would have to be converted back and forth. I assume, that a lot of client code will also make use of these existing implementations, since they are fairly standard and authoritative. Moreover, for standard library vectors, debuggers tend to be able to let the programmer inspect their contents more conveniently. I hope that at some stage, C++ itself will provide a matrix datatype - if this should ever happen, it is likely that it will be taken from the \texttt{boost} library.

\subsection{Two Interface Levels}
For certain tasks, the library supports 2 levels of interfacing - a more convenient high-level interface and a more performance efficient low-level interface. The idea is that you may write prototype code using the high-level interface which will result in readable code. Later, you may want translate that into production code using the low-level interface, which avoids certain overheads such as dynamic memory allocation. The low-level interface also gives you more options for tuning the runtime performance. For example, you may choose between different algorithms that perform the same task but have different numerical stability and efficiency properties. The low level interface will often operate on plain C-style arrays of your respective datatype. Some of those functions will assume that input and output arrays do not overlap while others may not care and therefore may be used 'in-place'. If in-place operation is possible, it will be said so in the documentation, otherwise assume it isn't.

% functions that need temporary memory may get an optional workspace parameter which defaults to nullptr, inside the function, the passed argument will be checked, if it is a nullptr, temporary memory will be allocated (and freed before exiting)

\subsection{Classes for Code Organization}
The code of the library is organized in classes such as \texttt{Polynomial, Matrix, FilterDesign, Transforms}, etc. which group together related functionality. This organizing principle is also used in cases where the client code is not supposed to instantiate any objects of a class. For example, the class \texttt{IntegerFunctions} is merely a collection of functions that perform common operations on integer numbers, such as \texttt{IntegerFunctions::gcd(T x, T y)} for finding the greatest common divisor of the two numbers \texttt{x, y} (of a templated integer type \texttt{T}). This makes it easier to find the required functionality than in an unorganized collection of functions that all occupy the same namespace. The generated doxygen documentation will also show related functions under a common 'headline'.

\subsection{Goals}
The primary goal is to provide a collection of audio processing algorithms that is practically useful in actual audio software products. Thus, the code should be reasonably efficient. A secondary goal for the library is to have educational value. That means, the code should be written in a readable way and familiar conventions known from signal processing literature and other DSP software libraries (such as MatLab's signal processing toolbox) should be followed, where reasonable. Sometimes, these two goals are in conflict - the most efficient implementation is sometimes not the most readable. In these cases, efficiency is most often preferred and complications in the code will often be annotated by comments. However, the library does not try to squeeze the last bit of performance out of the computer. Specifically, all code is plain C/C++ and there are no assembler optimizations or use of intrinsic SIMD types and functions. This wouldn't make sense in a type independent template based library anyway. However, if client code wraps SIMD datatypes and operations into classes, the template implementations of RAPT may be instantiated for these class types as well, potentially leading to higher performance - but such considerations will be left to client code.

%\subsection{Library Structure}
%The library is subdivided into....don't know yet

\section{Basic Examples}

\subsection{Butterworth Filter}
Suppose, you want to compute the coefficients of a 5th order Butterworth filter with a cutoff frequency of 1 kHz operating at a samplerate of 44.1 kHz. With RAPT, you may do this like this:
\begin{lstlisting}
double fs = 44100;     // samplerate
double fc =  1000;     // cutoff frequency
double b[6], a[6];     // filter coefficients
FilterDesign<double>::butterCoeffs(b, a, 5, 2*fc/fs);
\end{lstlisting}
The last line of this code snippet will fill the arrays \texttt{b, a} with the feedforward and feedback coefficients of a Butterworth filter in direct form, i.e. a filter that implements the difference equation:
\begin{equation}
  \label{Eq:FilterDiffEq}
	y_n = \sum_{k=0}^5 b_k x_{n-k} - \sum_{k=1}^5 a_k y_{n-k}
\end{equation}
Note that the frequency passed to the filter design routine is a normalized frequency, i.e. a frequency value between $0$ and $1$ where $1$ corresponds to the Nyquist frequency (half of the samplerate). This convention is used for frequencies throughout the library and is in line with usage in MatLab/Octave/SciPy/etc. [verify]. Next, suppose you have an array \texttt{x} of length \texttt{N} and you want to filter that array using the Butterworth coefficients. The output shall be stored in another array \texttt{y} of length \texttt{M}. This can be done by:
\begin{lstlisting}
Filter<double>::applyDF2(x, N, y, M, b, 5, a, 5);
\end{lstlisting}
this computes \texttt{M} output samples by applying the filter using a so called direct form II implementation structure. The length of the output \texttt{M} may be different from the length of the input \texttt{N}.

\subsubsection{A Realtime Implementation}
The code above applies the filter to the whole array \texttt{x} at once. This would be adequate only in situations, where you have the whole signal available, like in an audio editor application. But now imagine, for example, your product is a realtime audio plugin. In this case, you will typically have to write a subclass that is derived from a baseclass that comes from an audio plugin API. Such plugin APIs typically have some kind of audio callback function, often called \texttt{process}, that takes a short buffer of input samples as (pointer-type) parameter and is supposed to produce a corresponding buffer of output samples. The plugin programmer has to override this function in their derived subclass and do there whatever computations are needed to achieve the desired effect. For example, your \texttt{process} callback for a Butterworth filter plugin based on RAPT could look like:
\begin{lstlisting}
void MyFilterPlugin::process(int numSamples, int numChannels,
                             float **in, float **out)
{
  assert(numChannels == 2);                   // handles only stereo signals
	filterL.process(in[0], out[0], numSamples); // process left channel
	filterR.process(in[1], out[1], numSamples); // process right channel
}
\end{lstlisting}
where \texttt{filterL, filterR} are objects of the class \texttt{Filter}. Many of RAPT's audio processing classes provide such a process function. As you can see from the difference equation \ref{Eq:FilterDiffEq}, each filter output sample is computed as a weighted sum of the current input sample, past input samples and past output samples. An object of class \texttt{Filter} is responsible for keeping track of these in a realtime situation. In some situations, for example, when the user stops or restarts the audio playback in a digital audio workstation (DAW), it is appropriate to reset these state variables to their initial state (which is zero, in this case). The plugin interface will typically have another callback for you to override in these situations, for example called \texttt{suspend} in the VST API. There, you would call:
\begin{lstlisting}
void MyFilterPlugin::suspend()
{
	filterL.reset();
	filterR.reset();
}
\end{lstlisting}
In addition to the \texttt{process} callback, realtime audio plugin APIs also provide a means to let the user set up the plugin's parameters, typically in the form a \texttt{setParameter} function that is supposed to be called whenever the user changes a parameter. In our case, the user might want to change the filter's cutoff frequency from a GUI. Whenever the cutoff frequency is changed, the filter coefficients have to be recomputed. Our implementation could look like:
\begin{lstlisting}
void MyFilterPlugin::setParameter(int index, float value)
{
  switch( index )
  {
  case CUTOFF:
    {
      // User wants to change cutoff frequency.

      // Convert normalized parameter value to desired cutoff frequency:
      cutoff = RAPT::Conversions<float>::linToExp(value, 0, 1, 20, 20000);

      // Compute new filter coefficients:
      FilterDesign<float>::butterCoeffs(b, a, 5, 2*cutoff/samplerate);

      // Pass the new coefficients to the filter objects for left and right
      // channel:
      filterL.setCoeffs(b, a, 5);
      filterR.setCoeffs(b, a, 5);
    }
    break;
    // ... handle other parameter updates here
  }
}
\end{lstlisting}
This example is purely for instructional purposes and therefore kept simple. It's not the most efficient way to do it. Specifically, the call to \texttt{FilterDesign<double>::butterCoeffs} is computationally expensive. A rather elaborate mathematical machinery is invoked to compute these coefficients and they are always computed from scratch in such a call. It is possible to save some of the computational steps, by storing some intermediate results that are expensive to compute and don't change when the cutoff frequency is changed (namely the poles of the analog prototype filter). Furthermore, \texttt{setParameter} and \texttt{process} are typically called from different threads, so you may want to take some care about synchronization, for example by wrapping the two calls to \texttt{setCoeffs} and the two calls to \texttt{process} into a mutex lock. So, take this example code with a grain of salt - it shall just demonstrate the basic principles and is not production ready code. Note that you would also need to recompute the coefficients, when the samplerate changes. You will be informed about this in yet another callback.

\paragraph{Realtime and Latency} The above scheme is typical for realtime audio plugins, but the designation as 'realtime' has to be taken with a grain of salt. The plugin's audio callback is called with a given buffer size $B$, i.e. a certain number of samples to be processed. From the perspective of the host application, that means, when it wants to produce an output sample at a given time instant $n$, it must know all samples from $n$ up to $n+B-1$, so it can feed them into plugin's \texttt{process} callback already at instant $n$. Sometimes the host can't know these future samples in advance, for example because the host itself receives them from a realtime input. In such a case, it must first accumulate $B$ samples, then pass the buffer of $B$ samples to the plugin, receive the output and pass it on further down the signal chain. This wait-and-accumulate strategy introduces a delay of $B-1$ samples between input and output. Typically the buffer sizes are a couple of tens or hundreds of samples which translates to a couple of milliseconds or tens of milliseconds of delay. Delays below 10 ms are below the threshold of human perception, but it has to be kept in mind in certain situations, especially when similar signals are to be mixed. If the buffer size is just a single sample, there's no such delay and the mode of operation can be properly called 'realtime'. In some situations, such behavior is required, that's why the \texttt{Filter} class also provides a special \texttt{process} function which produces just a single output sample from a single input sample. An idiom, typically seen throughout the library in realtime capable classes, is that a buffer based \texttt{process} function actually calls a (possibly inlined) single sample based \texttt{process} function inside a loop that runs over all the samples in the buffer. If you are building a modular system with modules from RAPT and you want to introduce a feedback loop in a modular patch, you will probably want to use the the sample based processing functions. In this context, your feedback loop will then only have a single sample of delay - you can use the output of a module produced at instant $n$ as input to the same module from instant $n+1$ onwards.

\subparagraph{Zero Delay Feedback}
In cases where even that single sample of delay in the feedback path is too much, you can use special \texttt{processNoUpdate} functions which can produce the output sample without updating the internal state of the object. Using these functions, you might be able to set up a convergent iteration [t.b.c. ...]. %Such a scheme is called a fixpoint iteration - bett

%\subsection{Frequency Analysis}
%\subsection{Interpolation}


\subsection{Omitted variable bias}

If the producer sees customer characteristics we do not, then there will be a bias in our estimate.

Producers will set prices correlated with those characteristics.


\section{Bilinear forms}


\chapter{Bytevectors}
\label{bytevectorschapter}

Many applications deal with blocks of binary data by accessing
them in various ways---extracting signed or unsigned numbers of
various sizes.  Therefore, the \defrsixlibrary{bytevectors} library
provides a single type for
blocks of binary data with multiple ways to access that data. It deals
with integers and floating-point representations
in various sizes with specified endianness.

Bytevectors\mainindex{bytevector} are objects of a disjoint
type. Conceptually, a bytevector represents a sequence of 8-bit
bytes.  The description of bytevectors uses the term \defining{byte}
for an exact integer object in the interval $\{-128, \ldots, 127\}$ and the
term \defining{octet} for an exact integer object in the interval $\{0,
\ldots, 255\}$.  A byte corresponds to its two's complement
representation as an octet.

The length of a bytevector is the number of bytes it contains. This
number is fixed. A valid index into a bytevector is an exact,
non-negative integer object less than the length of the bytevector.
The first byte of a bytevector has index 0;
the last byte has an index one less than the length of the bytevector.

Generally, the access procedures come in different flavors according
to the size of the represented integer and the endianness of the
representation.  The procedures also distinguish signed and unsigned
representations.
The signed representations all use two's complement.

Like string literals, literals representing bytevectors do not need to
be quoted:
%
\begin{scheme}
\#vu8(12 23 123) \ev \#vu8(12 23 123)%
\end{scheme}

\section{Endianness}

Many operations described in this chapter accept an
\defining{endianness} argument.  Endianness describes the encoding of
exact integer objects as several contiguous bytes in a bytevector~\cite{IEN137}.
For this purpose, the binary representation of the integer object is split into
consecutive bytes.  \mainindex{little-endian}The little-endian
encoding places the least significant byte of an integer first, with
the other bytes following in increasing order of significance.
\mainindex{big-endian}The big-endian encoding places the most
significant byte of an integer first, with the other bytes following
in decreasing order of significance.

This terminology also applies to IEEE-754 numbers: IEEE~754 describes
how to represent a floating-point number as an exact integer object, and
endianness describes how the bytes of such an integer are laid out in
a bytevector.

\begin{note}
  Little- and big-endianness are only the most common kinds of
  endianness.  Some architectures distinguish between the endianness
  at different levels of a binary representation.
\end{note}

\section{General operations}

\begin{entry}{%
\proto{endianness}{ \hyper{endianness symbol}}{\exprtype}}

\domain{The name of \hyper{endianness symbol} must be a symbol describing an
  endianness.  An implementation must support at least the symbols
  {\cf big} and {\cf little}, but may support other endianness
  symbols.}  {\cf (endianness \hyper{endianness symbol})} evaluates to
the symbol named \hyper{endianness symbol}.  Whenever one of the
procedures operating on bytevectors accepts an endianness as an
argument, that argument must be one of these symbols.  It is a syntax
violation for \hyper{endianness symbol} to be anything other than an
endianness symbol supported by the implementation.

\begin{note}
  Implementors should use widely accepted designations
  for endianness symbols other than {\cf big} and {\cf little}.
\end{note}

\begin{note}
  Only the name of \hyper{endianness symbol} is significant.
\end{note}
\end{entry}

\begin{entry}{%
\proto{native-endianness}{}{procedure}}

Returns the endianness symbol associated implementation's preferred
endianness (usually that of the underlying machine architecture).
This may be any \hyper{endianness symbol}, including a symbol other
than {\cf big} and {\cf little}.
\end{entry}

\begin{entry}{%
\proto{bytevector?}{ obj}{procedure}}

Returns \schtrue{} if \var{obj} is a bytevector,
otherwise returns \schfalse{}.
\end{entry}

\begin{entry}{%
\proto{make-bytevector}{ k}{procedure}
\rproto{make-bytevector}{ k fill}{procedure}}

Returns a newly allocated bytevector of \var{k} bytes.

If the \var{fill} argument is missing, the initial contents of the
returned bytevector are unspecified.

If the \var{fill} argument is present, it must be an exact integer
object in
the interval $\{-128, \ldots 255\}$ that specifies the initial value
for the bytes of the bytevector: If \var{fill} is positive, it is
interpreted as an octet; if it is negative, it is interpreted as a byte.
\end{entry}

\begin{entry}{%
\proto{bytevector-length}{ bytevector}{procedure}}

Returns, as an exact integer object, the number of bytes in \var{bytevector}.
\end{entry}

\begin{entry}{%
\proto{bytevector=?}{ \vari{bytevector} \varii{bytevector}}{procedure}}

Returns \schtrue{} if \vari{bytevector} and \varii{bytevector} are equal---that
is, if they have the same length and equal bytes at all valid indices.
It returns \schfalse{} otherwise.
\end{entry}

\begin{entry}{%
\proto{bytevector-fill!}{ bytevector fill}{procedure}}

\domain{The \var{fill} argument is as in the description of the {\cf
    make-bytevector} procedure.}
The {\cf bytevector-fill!} procedure stores \var{fill} in every element of \var{bytevector}
and returns \unspecifiedreturn.  Analogous to {\cf vector-fill!}.
\end{entry}

\begin{entry}{%
\pproto{(bytevector-copy! \var{source} \var{source-start}}{procedure}}
\mainschindex{bytevector-copy!}{\tt\obeyspaces\\
     \var{target} \var{target-start} \var{k})}

\domain{\var{Source} and \var{target} must be bytevectors.
  \var{Source-start}, \var{target-start},
  and \var{k} must be non-negative exact integer objects that satisfy

  \begin{displaymath}
    \begin{array}{rcccccl}
      0 & \leq & \var{source-start} & \leq & \var{source-start} + \var{k} & \leq & l_{\var{source}}
      \\
      0 & \leq & \var{target-start} & \leq & \var{target-start} + \var{k} & \leq & l_{\var{target}}
    \end{array}
  \end{displaymath}
  %
  where $l_{\var{source}}$ is the length of \var{source} and
  $l_{\var{target}}$ is the length of \var{target}.}

  The {\cf bytevector-copy!} procedure copies the bytes from \var{source} at indices
  \begin{displaymath}
     \var{source-start}, \ldots, \var{source-start} + \var{k} - 1
  \end{displaymath}
  to consecutive indices in \var{target} starting at \var{target-index}.

  This must work even if the memory regions for the source and the target
  overlap, i.e., the bytes at the target location after the copy must be
  equal to the bytes at the source location before the copy.

  This returns \unspecifiedreturn.
\begin{scheme}
(let ((b (u8-list->bytevector '(1 2 3 4 5 6 7 8))))
  (bytevector-copy! b 0 b 3 4)
  (bytevector->u8-list b)) \ev (1 2 3 1 2 3 4 8)%
\end{scheme}
\end{entry}

\begin{entry}{%
\proto{bytevector-copy}{ bytevector}{procedure}}

Returns a newly allocated copy of \var{bytevector}.
\end{entry}

\section{Operations on bytes and octets}

\begin{entry}{%
\proto{bytevector-u8-ref}{ bytevector k}{procedure}
\proto{bytevector-s8-ref}{ bytevector k}{procedure}}

\domain{\var{K} must be a valid index of \var{bytevector}.}

The {\cf bytevector-u8-ref} procedure returns the byte at index \var{k} of \var{bytevector},
as an octet.

The {\cf bytevector-s8-ref} procedure returns the byte at index \var{k} of \var{bytevector},
as a (signed) byte.

\begin{scheme}
(let ((b1 (make-bytevector 16 -127))
      (b2 (make-bytevector 16 255)))
  (list
    (bytevector-s8-ref b1 0)
    (bytevector-u8-ref b1 0)
    (bytevector-s8-ref b2 0)
    (bytevector-u8-ref b2 0))) \lev (-127 129 -1 255)%
\end{scheme}
\end{entry}

\begin{entry}{%
\proto{bytevector-u8-set!}{ bytevector k octet}{procedure}
\proto{bytevector-s8-set!}{ bytevector k byte}{procedure}}

\domain{\var{K} must be a valid index of \var{bytevector}.}

The {\cf bytevector-u8-set!} procedure stores \var{octet} in element \var{k} of
\var{bytevector}.

The {\cf bytevector-s8-set!} procedure stores the two's-complement representation of
\var{byte} in element \var{k} of \var{bytevector}.

Both procedures return \unspecifiedreturn.

\begin{scheme}
(let ((b (make-bytevector 16 -127)))

  (bytevector-s8-set! b 0 -126)
  (bytevector-u8-set! b 1 246)

  (list
    (bytevector-s8-ref b 0)
    (bytevector-u8-ref b 0)
    (bytevector-s8-ref b 1)
    (bytevector-u8-ref b 1))) \lev (-126 130 -10 246)%
\end{scheme}
\end{entry}

\begin{entry}{%
\proto{bytevector->u8-list}{ bytevector}{procedure}
\proto{u8-list->bytevector}{ list}{procedure}}

\domain{\var{List} must be a list of octets.}

The {\cf bytevector->u8-list} procedure returns a newly allocated list of the octets of
\var{bytevector} in the same order.

The {\cf u8-list->bytevector} procedure returns a newly allocated bytevector whose
elements are the elements of list \var{list}, in
the same order.  It is analogous to {\cf list->vector}.
\end{entry}

\section{Operations on integers of arbitrary size}

\begin{entry}{%
\proto{bytevector-uint-ref}{ bytevector k endianness size}{procedure}
\proto{bytevector-sint-ref}{ bytevector k endianness size}{procedure}
\proto{bytevector-uint-set!}{ bytevector k n endianness size}{procedure}
\proto{bytevector-sint-set!}{ bytevector k n endianness size}{procedure}}

\domain{\var{Size} must be a positive exact integer object. $\var{K}, \ldots,
  \var{k} + \var{size} - 1$ must be valid indices of \var{bytevector}.}

The {\cf bytevector-uint-ref} procedure retrieves the exact integer object corresponding to the
unsigned representation of size \var{size} and specified by \var{endianness}
at indices $\var{k}, \ldots, \var{k} + \var{size} - 1$.

The {\cf bytevector-sint-ref} procedure retrieves the exact integer object corresponding to the two's-complement representation of size \var{size} and specified by \var{endianness} at
indices $\var{k}, \ldots, \var{k} + \var{size} - 1$.

\domain{For {\cf bytevector-uint-set!}, \var{n} must be an exact
  integer object in the interval $\{0, \ldots, 256^{\mathit{size}}-1\}$.}

The {\cf bytevector-uint-set!} procedure stores the unsigned representation of size \var{size}
and specified by \var{endianness} into \var{bytevector} at indices
$\var{k}, \ldots, \var{k} + \var{size} - 1$.

\domain{For {\cf bytevector-sint-set!}, \var{n} must be an exact
  integer object in
  the interval $\{-256^{\mathit{size}}/2, \ldots,
  256^{\mathit{size}}/2-1\}$.}
{\cf bytevector-sint-set!} stores the two's-complement
representation of size \var{size} and specified by \var{endianness}
into \var{bytevector} at indices $\var{k}, \ldots, \var{k} + \var{size} - 1$.

The \ldots{\cf -set!} procedures return \unspecifiedreturn.

\begin{scheme}
(define b (make-bytevector 16 -127))

(bytevector-uint-set! b 0 (- (expt 2 128) 3)
                     (endianness little) 16)

(bytevector-uint-ref b 0 (endianness little) 16)\lev
    \#xfffffffffffffffffffffffffffffffd

(bytevector-sint-ref b 0 (endianness little) 16)\lev -3

(bytevector->u8-list b)\lev (253 255 255 255 255 255 255 255
               255 255 255 255 255 255 255 255)

(bytevector-uint-set! b 0 (- (expt 2 128) 3)
                 (endianness big) 16)
(bytevector-uint-ref b 0 (endianness big) 16) \lev
    \#xfffffffffffffffffffffffffffffffd

(bytevector-sint-ref b 0 (endianness big) 16) \lev -3

(bytevector->u8-list b) \lev (255 255 255 255 255 255 255 255
               255 255 255 255 255 255 255 253))%
\end{scheme}
\end{entry}

\begin{entry}{%
\proto{bytevector->uint-list}{ bytevector endianness size}{procedure}
\proto{bytevector->sint-list}{ bytevector endianness size}{procedure}
\proto{uint-list->bytevector}{ list endianness size}{procedure}
\proto{sint-list->bytevector}{ list endianness size}{procedure}}

\domain{\var{Size} must be a positive exact integer object.  For {\cf
    uint-list->bytevector}, \var{list} must be a list of exact
  integer objects in the interval $\{0, \ldots, 256^{\mathit{size}}-1\}$.  For
  {\cf sint-list->bytevector}, \var{list} must be a list of exact
  integer objects in the interval $\{-256^{\mathit{size}}/2, \ldots,
  256^{\mathit{size}}/2-1\}$.  The length of \var{bytevector}
  must be divisible by \var{size}.}

These procedures convert between lists of integer objects and their consecutive
representations according to \var{size} and \var{endianness} in the
\var{bytevector} objects in the same way as {\cf bytevector->u8-list} and {\cf
  u8-list->bytevector} do for one-byte representations.

\begin{scheme}
(let ((b (u8-list->bytevector '(1 2 3 255 1 2 1 2))))
  (bytevector->sint-list b (endianness little) 2)) \lev (513 -253 513 513)

(let ((b (u8-list->bytevector '(1 2 3 255 1 2 1 2))))
  (bytevector->uint-list b (endianness little) 2)) \lev (513 65283 513 513)%
\end{scheme}
\end{entry}

\section{Operations on 16-bit integers}

\begin{entry}{%
\proto{bytevector-u16-ref}{ bytevector k endianness}{procedure}
\proto{bytevector-s16-ref}{ bytevector k endianness}{procedure}
\proto{bytevector-u16-native-ref}{ bytevector k}{procedure}
\proto{bytevector-s16-native-ref}{ bytevector k}{procedure}
\proto{bytevector-u16-set!}{ bytevector k n endianness}{procedure}
\proto{bytevector-s16-set!}{ bytevector k n endianness}{procedure}
\proto{bytevector-u16-native-set!}{ bytevector k n}{procedure}
\proto{bytevector-s16-native-set!}{ bytevector k n}{procedure}}

\domain{\var{K} must be a valid index of \var{bytevector}; so must
  $\var{k} + 1$. For {\cf bytevector-u16-set!} and {\cf
    bytevector-\hp{}u16-native-\hp{}set!}, \var{n} must be an exact integer object in
  the interval $\{0, \ldots, 2^{16}-1\}$.  For {\cf bytevector-s16-set!}
  and {\cf bytevector-s16-native-set!}, \var{n} must be an exact
  integer object in the interval $\{-2^{15}, \ldots, 2^{15}-1\}$.}

These retrieve and set two-byte representations of numbers at indices
\var{k} and $\var{k}+1$, according to the endianness specified by
\var{endianness}. The procedures with {\cf u16} in their names deal with the
unsigned representation; those with {\cf s16} in their names deal
with the two's-complement representation.

The procedures with {\cf native} in their names employ the native
endianness, and work only at aligned indices:
\var{k} must be a multiple of 2.

The \ldots{\cf -set!} procedures return \unspecifiedreturn.

\begin{scheme}
(define b
  (u8-list->bytevector
    '(255 255 255 255 255 255 255 255
      255 255 255 255 255 255 255 253)))

(bytevector-u16-ref b 14 (endianness little)) \lev 65023
(bytevector-s16-ref b 14 (endianness little)) \lev -513
(bytevector-u16-ref b 14 (endianness big)) \lev 65533
(bytevector-s16-ref b 14 (endianness big)) \lev -3

(bytevector-u16-set! b 0 12345 (endianness little))
(bytevector-u16-ref b 0 (endianness little)) \lev 12345

(bytevector-u16-native-set! b 0 12345)
(bytevector-u16-native-ref b 0) \ev 12345

(bytevector-u16-ref b 0 (endianness little)) \lev \unspecified%
\end{scheme}
\end{entry}

\section{Operations on 32-bit integers}

\begin{entry}{%
\proto{bytevector-u32-ref}{ bytevector k endianness}{procedure}
\proto{bytevector-s32-ref}{ bytevector k endianness}{procedure}
\proto{bytevector-u32-native-ref}{ bytevector k}{procedure}
\proto{bytevector-s32-native-ref}{ bytevector k}{procedure}
\proto{bytevector-u32-set!}{ bytevector k n endianness}{procedure}
\proto{bytevector-s32-set!}{ bytevector k n endianness}{procedure}
\proto{bytevector-u32-native-set!}{ bytevector k n}{procedure}
\proto{bytevector-s32-native-set!}{ bytevector k n}{procedure}}

\domain{$\var{K}, \ldots, \var{k}+ 3$ must be valid indices of
  \var{bytevector}.
  For {\cf bytevector-u32-set!} and {\cf
    bytevector-\hp{}u32-\hp{}native-\hp{}set!}, \var{n} must be an exact integer
  object in
  the interval $\{0, \ldots, 2^{32}-1\}$.  For {\cf bytevector-s32-set!}
  and {\cf bytevector-s32-native-set!}, \var{n} must be an exact
  integer object in the interval $\{-2^{31}, \ldots, 2^{31}-1\}$.}

These retrieve and set four-byte representations of numbers at indices $\var{k},
\ldots, \var{k}+ 3$, according to the endianness specified by \var{endianness}. The
procedures with {\cf u32} in their names deal with the unsigned representation;
those with {\cf s32} with the two's-complement representation.

The procedures with {\cf native} in their names employ the native endianness, and
work only at aligned indices: \var{k} must be a multiple of 4.

The \ldots{\cf{}-set!} procedures return \unspecifiedreturn.

\begin{scheme}
(define b
  (u8-list->bytevector
    '(255 255 255 255 255 255 255 255
      255 255 255 255 255 255 255 253)))

(bytevector-u32-ref b 12 (endianness little)) \lev 4261412863
(bytevector-s32-ref b 12 (endianness little)) \lev -33554433
(bytevector-u32-ref b 12 (endianness big)) \lev 4294967293
(bytevector-s32-ref b 12 (endianness big)) \lev -3%
\end{scheme}
\end{entry}

\section{Operations on 64-bit integers}

\begin{entry}{%
\proto{bytevector-u64-ref}{ bytevector k endianness}{procedure}
\proto{bytevector-s64-ref}{ bytevector k endianness}{procedure}
\proto{bytevector-u64-native-ref}{ bytevector k}{procedure}
\proto{bytevector-s64-native-ref}{ bytevector k}{procedure}
\proto{bytevector-u64-set!}{ bytevector k n endianness}{procedure}
\proto{bytevector-s64-set!}{ bytevector k n endianness}{procedure}
\proto{bytevector-u64-native-set!}{ bytevector k n}{procedure}
\proto{bytevector-s64-native-set!}{ bytevector k n}{procedure}}

\domain{$\var{K}, \ldots, \var{k}+ 7$ must be valid indices of
  \var{bytevector}.
  For {\cf bytevector-u64-set!} and {\cf
    bytevector-\hp{}u64-\hp{}native-\hp{}set!}, \var{n} must be an exact integer
  object in
  the interval $\{0, \ldots, 2^{64}-1\}$.  For {\cf bytevector-s64-set!}
  and {\cf bytevector-s64-native-set!}, \var{n} must be an exact
  integer object in the interval $\{-2^{63}, \ldots, 2^{63}-1\}$.}

These retrieve and set eight-byte representations of numbers at
indices $\var{k}, \ldots, \var{k}+ 7$, according to the endianness
specified by \var{endianness}. The procedures with {\cf u64} in their names deal
with the unsigned representation; those with {\cf s64} with the
two's-complement representation.

The procedures with {\cf native} in their names employ the native endianness, and
work only at aligned indices: \var{k} must be a multiple of 8.

The \ldots{\cf{}-set!} procedures return \unspecifiedreturn.

\begin{scheme}
(define b
  (u8-list->bytevector
    '(255 255 255 255 255 255 255 255
      255 255 255 255 255 255 255 253)))

(bytevector-u64-ref b 8 (endianness little)) \lev 18302628885633695743
(bytevector-s64-ref b 8 (endianness little)) \lev -144115188075855873
(bytevector-u64-ref b 8 (endianness big)) \lev 18446744073709551613
(bytevector-s64-ref b 8 (endianness big)) \lev -3%
\end{scheme}
\end{entry}

\section{Operations on IEEE-754 representations}

\begin{entry}{%
\proto{bytevector-ieee-single-native-ref}{ bytevector k}{procedure}
\proto{bytevector-ieee-single-ref}{ bytevector k endianness}{procedure}}

\domain{$\var{K}, \ldots, \var{k}+3$ must be valid indices of
  \var{bytevector}.  For {\cf bytevector-ieee-single-native-ref}, \var{k} must
  be a multiple of $4$.}

These procedures return the inexact real number object that best
represents the IEEE-754 single-precision number represented by the
four bytes beginning at index
\var{k}.
\end{entry}

\begin{entry}{%
\proto{bytevector-ieee-double-native-ref}{ bytevector k}{procedure}
\proto{bytevector-ieee-double-ref}{ bytevector k endianness}{procedure}}

\domain{$\var{K}, \ldots, \var{k}+7$ must be valid indices of
  \var{bytevector}.  For {\cf bytevector-ieee-double-native-ref}, \var{k} must
  be a multiple of $8$.}

These procedures return the inexact real number object that best
represents the IEEE-754 double-precision number represented by the
eight bytes beginning at index \var{k}.
\end{entry}

\begin{entry}{%
\proto{bytevector-ieee-single-native-set!}{ bytevector k x}{procedure}
\pproto{(bytevector-ieee-single-set! \var{bytevector}}{procedure}}
{\tt\obeyspaces\\
     \var{k} \var{x} \var{endianness})}

\domain{$\var{K}, \ldots, \var{k}+3$ must be valid indices of
  \var{bytevector}.  For {\cf bytevector-ieee-single-native-set!}, \var{k} must
  be a multiple of $4$.}

These procedures store an IEEE-754 single-precision representation of \var{x} into
elements \var{k} through $\var{k}+3$ of \var{bytevector}, and return
\unspecifiedreturn.
\end{entry}

\begin{entry}{%
\proto{bytevector-ieee-double-native-set!}{ bytevector k x}{procedure}
\pproto{(bytevector-ieee-double-set! \var{bytevector}}{procedure}}
{\tt\obeyspaces\\
     \var{k} \var{x} \var{endianness})}

\domain{$\var{K}, \ldots, \var{k}+7$ must be valid indices of
  \var{bytevector}.  For {\cf bytevector-ieee-double-native-set!}, \var{k} must
  be a multiple of $8$.}

These procedures store an IEEE-754 double-precision representation of \var{x} into
elements \var{k} through $\var{k}+7$ of \var{bytevector}, and return
\unspecifiedreturn.
\end{entry}

\section{Operations on strings}

This section describes procedures that convert between strings and
bytevectors containing Unicode encodings of those strings.  When
decoding bytevectors, encoding errors are handled as with the {\cf
  replace} semantics of textual I/O (see
section~\ref{transcoderssection}): If an invalid or incomplete
character encoding is encountered, then the replacement character
U+FFFD is appended to the string being generated, an appropriate
number of bytes are ignored, and decoding continues with the following
bytes.

\begin{entry}{%
\proto{string->utf8}{ string}{procedure}}

Returns a newly allocated (unless empty) bytevector that
contains the UTF-8 encoding of the given string.
\end{entry}

\begin{entry}{%
\proto{string->utf16}{ string}{procedure}
\rproto{string->utf16}{ string endianness}{procedure}}

\domain{If \var{endianness} is specified, it must be the symbol {\cf
    big} or the symbol {\cf little}.}  The {\cf string->utf16}
  procedure returns a newly allocated (unless empty) bytevector that
contains the UTF-16BE or UTF-16LE encoding of the given string (with
no byte-order mark).  If endianness is not specified or is {\cf big},
then UTF-16BE is used.  If endianness is {\cf little}, then UTF-16LE
is used.
\end{entry}

\begin{entry}{%
\proto{string->utf32}{ string}{procedure}
\rproto{string->utf32}{ string endianness}{procedure}}

\domain{If \var{endianness} is specified, it must be the symbol {\cf
    big} or the symbol {\cf little}.}  The {\cf string->utf32}
procedure returns
a newly allocated (unless empty) bytevector that contains the UTF-32BE
or UTF-32LE encoding of the given string (with no byte mark).  If
endianness is not specified or is {\cf big}, then UTF-32BE is used.
If endianness is {\cf little}, then UTF-32LE is used.
\end{entry}

\begin{entry}{%
\proto{utf8->string}{ bytevector}{procedure}}

Returns a newly allocated (unless empty) string whose character
sequence is encoded by the given bytevector.
\end{entry}

\begin{entry}{%
\proto{utf16->string}{ bytevector endianness}{procedure}
\pproto{(utf16->string \var{bytevector}}{procedure}}
{\tt\obeyspaces\\
    \var{endianness} \var{endianness-mandatory?})}

\domain{\var{Endianness} must be the symbol {\cf big} or
  the symbol {\cf little}.} The {\cf utf16->string} procedure returns
a newly allocated (unless empty) string whose character sequence is
encoded by the given bytevector.  \var{Bytevector} is decoded according
to UTF-16, UTF-16BE, UTF-16LE, or a fourth encoding scheme that differs from
all three of those as follows: If \var{endianness-mandatory?} is
absent or \schfalse, {\cf utf16->string} determines the endianness
according to a UTF-16 BOM at the beginning of \var{bytevector} if a
BOM is present; in this case, the BOM is not decoded as a character.
Also in this case, if no UTF-16 BOM is present, \var{endianness}
specifies the endianness of the encoding.  If
\var{endianness-mandatory?} is a true value, \var{endianness}
specifies the endianness of the encoding, and any UTF-16 BOM in the
encoding is decoded as a regular character.

\begin{note}
  A UTF-16 BOM is either a sequence of bytes \sharpsign{}xFE,
  \sharpsign{}xFF specifying {\cf big} and UTF-16BE, or \sharpsign{}xFF,
  \sharpsign{}xFE specifying {\cf little} and UTF-16LE.
\end{note}
\end{entry}

\begin{entry}{%
\proto{utf32->string}{ bytevector endianness}{procedure}
\pproto{(utf32->string \var{bytevector}}{procedure}}
{\tt\obeyspaces\\
    \var{endianness} \var{endianness-mandatory?})}

\domain{\var{Endianness} must be the symbol {\cf big} or
  the symbol {\cf little}.} The {\cf utf32->string} procedure returns
a newly allocated (unless empty) string whose character sequence is
encoded by the given bytevector.  \var{Bytevector} is decoded according
to UTF-32, UTF-32BE, UTF-32LE, or a fourth encoding scheme that differs from
all three of those as follows: If \var{endianness-mandatory?} is
absent or \schfalse, {\cf utf32->string} determines the endianness
according to a UTF-32 BOM at the beginning of \var{bytevector} if a
BOM is present; in this case, the BOM is not decoded as a character.
Also in this case, if no UTF-32 BOM is present, \var{endianness}
specifies the endianness of the encoding.  If
\var{endianness-mandatory?} is a true value, \var{endianness}
specifies the endianness of the encoding, and any UTF-32 BOM in the
encoding is decoded as a regular character.

\begin{note}
  A UTF-32 BOM is either a sequence of bytes \sharpsign{}x00,
  \sharpsign{}x00, \sharpsign{}xFE, \sharpsign{}xFF specifying {\cf
    big} and UTF-32BE, or \sharpsign{}xFF, \sharpsign{}xFE,
  \sharpsign{}x00, \sharpsign{}x00, specifying {\cf little} and
  UTF-32LE.
\end{note}
\end{entry}

%%% Local Variables:
%%% mode: latex
%%% TeX-master: "r6rs-lib"
%%% End:


%!TEX root = thesis.tex
\chapter{\code{FASMA} and machine learning}
\label{cha:fasmaML}

With the increasing amount of astrophysical data, it is important to perform a rapid and trustworthy
analysis. This is one of the strengths for \code{FASMA} when dealing with high quality spectroscopic
data for determination of stellar atmospheric parameters. Here a classic method to analyse these
large amount of data has been modernised with a new minimisation technique that utilise the physical
knowledge about the system. However smart it may sound like, it can be improved. The time consuming
part in \code{FASMA} are the calls to \code{MOOG}. In the end a couple of minutes are spent on the
minimisation on a modern computer.

This lead to a side-project: explorer the use of machine learning to determine stellar atmospheric
parameters. Machine learning (ML) is not a new topic in computer science, but it is a tool that is
steadily becoming more and more popular in today's science. The effort of using ML here is meant as
a proof of concept, and something that can be improved upon in the future.

The idea was to remove the expensive calls to \code{MOOG} completely. Two things are required in
order to do so in the approach presented here:
\begin{enumerate}
  \item Stellar atmospheric parameters of a large sample of stars with a big span in the parameter
        space
  \item The EW measurements of as many absorption lines as possible (in this case \ion{Fe}{I} and
        \ion{Fe}{II})
\end{enumerate}
Additionally it is here required that the above two points are obtained in a homogeneous way.
Luckily such a sample was already analysed during this thesis as a test of \code{FASMA} (see
\sref{sec:fasma_test}) where a sample of 582 stars were analysed; all of which meet the above
required criteria.

This data set of measurements of EWs and the parameters were organised and prepared in a big table
as follows:
\begin{itemize}
  \item Each row contains both the measurements of the EWs (first N columns) and the parameters
        (last four columns). The parameters are $T_\mathrm{eff}$, $\log g$, $[\ion{Fe}/\ion{H}]$,
        and $\xi_\mathrm{micro}$
  \item The columns excluding the last four are labelled with the wavelength of the absorption line
  \item All wavelength columns which contained at least one missing measurement of the EW for any
        of the 582 stars were removed
\end{itemize}
There are 58 wavelength columns after removing wavelength columns with missing measurements. Before
the removal there were 299 columns with wavelength. In this case the \code{scikit-learn}
package\footnote{\url{http://scikit-learn.org/}} from the Python ecosystem was used to train the
data set. This also package also include a tool to split the data into a training part and testing
part. This is particular useful when trying to evaluate the accuracy of the model used. Here the
training consist of 2/3 of the data, and the rest is for testing. This splitting is done randomly,
giving slight different results each time the script is executed.

The training itself is quite fast (less than \SI{10}{s}). However, the real power comes when the
trained model is saved to the disk, which can later be loaded again. In this way the training will
only be done once. Using the model to obtain the parameters is much less than \SI{1}{s}, which makes
is many orders of magnitudes faster\footnote{Improvements in the order of millions have been
obtained here.} than a more traditional approach as with \code{FASMA}.

When testing the model trained, the 1/3 data set is used to derive parameters. Those derived
parameters are then compared to the actual parameters with a mean absolute error. This gives an idea
of the accuracy. In \fref{fig:ml} the script was run 1000 times (the splitting was done randomly in
each run), and the error for each parameter is shown as a histogram. The mean errors for each
parameters are roughly $T_\mathrm{eff}:\SI{47}{K}$, $\log g:\SI{0.10}{dex}$,
$[\ion{Fe}/\ion{H}]:\SI{0.038}{dex}$, and $\xi_\mathrm{micro}:\SI{0.12}{km/s}$.

\begin{figure}[htpb!]
    \centering
    \includegraphics[width=1.0\linewidth]{figures/ML.pdf}
    \caption{Mean absolute error on each parameter after 1000 runs.}
    \label{fig:ml}
\end{figure}

There exists many different algorithms within \code{scikit-learn} to train the final model. In the
test here a simple \code{LinearRegression} was used. Other algorithms were tested as well, such as
\code{Ridge} and \code{Lasso}, however with very similar results. The main difference between the
different algorithms are found in the details on how the minimisation is done. This is described in
great detail in the online documentation.


\subsection{Line integral}


% !TEX root = manual.tex

\chapter{Uncertainty Quantification Methods and Tools}
\label{chapter:uq}

\section{Overview}
\label{sec:uqoverview}
The SST/macro UQ workflow generally occurs in two steps:
\begin{itemize}
\item Generating and running parameter sweep
\item Running calibration and sensitivity analysis
\end{itemize}

For uncertainty quantification (UQ) and validation studies the UQ Toolkit (UQTk) library is used.
UQTk (\url{www.sandia.gov/UQToolkit}) is a lightweight C++ library, developed in Sandia National Laboratories, California,
that primarily offers tools for surrogate model construction and uncertainty propagation with
polynomial chaos expansions (PCE), as well as model calibration and validation.

UQTk Version 2.0 is released under the GNU Lesser General Public License (LGPL).
A tar-ball with the source code, tutorials, examples and documentation can be
downloaded from \url{www.sandia.gov/UQToolkit/uqtk\_download.html}
UQTk uses a standard CMake build system.
Fortran (and libgfortran) is required.
The two basic UQ tasks, enabled by UQTk, are \emph{forward UQ} and \emph{inverse UQ} as outlined in the next subsections.

\section{Parameter Sweep and Data Collection}

Performing uncertainty quantification and sensitivity analysis requires sampling across a multi-dimensional parameter space.
Here the multi-dimensional input parameters covers all the latency, bandwidth, and size parameters for a given machine configuration.
In practical usage, a large parameter sweep must be performed to build a surrogate model.
The surrogate model must cover all observables - outputs or statistics of interest from the simulation.
That surrogate model is then used in a Markov Chain Monte-Carlo (MCMC) workflow to derive properties such as:

\begin{itemize}
\item Output sensitvity to input parameters
\item Maximum likelihood values of input parameters
\item Posterior distribution showing for each parameter showing uncertainties
\end{itemize}

\subsection{Surrogate Construction}
\label{subsec:surrogateConstruction}
SST/macro provides helper scripts in the folder \inlineshell{bin/uq} to generate and collect the data for surrogate construction.
The following steps must be performed:

\begin{itemize}
\item Create a template file (see \inlineshell{exampleTemplate.ini} for example). Variables such as \$link\_bw are marked to be replaced.
\item Create a parameter definition file (see \inlineshell{exampleParams} example file). Each variable to explore should match the \$name in the template file. Each parameter must define the range of values to explore. These define the ``prior distribution'' of realistic values for each parameter with min and max for the range given.
\item Run \inlineshell{generate_quad} installed by UQTk. This will create a file \inlineshell{qdpts.dat} defining the parameter sweep to perform.
\item Run \inlineshell{genSweep} using \inlineshell{qdpts.dat} to generate all the input \inlineshell{params_N.ini} files for each point in the sweep.
\item Run \inlineshell{genRunScript} to create a script \inlineshell{runAll} for running all the jobs in parallel on a given machine.
\item Make sure the \inlineshell{runSubSweep} script is in the same folder as \inlineshell{runAll}. Run the \inlineshell{runAll} script. Wait until a \inlineshell{testN.out} file matching all the .ini files is generated.
\item Gather the results. This must be re-written for each study. An example file \inlineshell{gatherResults} shows the basic idea. A final file, e.g. \inlineshell{results.out}, must be
created with one line for each .ini file.  Each line must contain all the output observables corresponding to the run.
\end{itemize}

The files \inlineshell{qdpts.dat} and \inlineshell{results.out} are enough to build the surrogate.

\subsection{Surrogate Validation}
The surrogate is a polynomial fit to the actual observed values.
To test how well the surrogate is able to reproduce the actual simulation, a random set of parameter points should be run through the simulator and compared to the surrogate estimates.
SST/macro provides a helper script \inlineshell{genRandom} to create a \inlineshell{samples.dat} file.
The \inlineshell{samples.dat} file is equivalent to \inlineshell{qdpts.dat} in the surrogate construction phase.
Once \inlineshell{samples.dat} is generated, all the same steps should be followed as in Section \ref{subsec:surrogateConstruction}.

\subsection{Experimental Comparison}
The simulator is trying to reproduce experimental values collected from an actual machine.
These experimental values are the ``nominally correct'' values.
The parameter calibration and sensitivity analysis,
must compare to the nominally correct values.
Usually these will come from a test bed or existing system,
but may come from, e.g. higher-accuracy simulations.
A file \inlineshell{experiments.out} should be generated that matches the format of \inlineshell{results.out} (one line per experimental trial, all output observables on a given line).
While only a single line of data is minimally required,
having multiple trials will improve the UQ workflow by including experimental noise into the uncertainty quantification.

Once you have all three output files (simulation results, random simulation samples, and experimental results),
surrogate construction and analysis can take place using UQTk.

\subsection{Initial Sanity Checks}
To sanity check the match between the simulation parameter sweep and the experimental values,
SST/macro provides a helper script \inlineshell{validatePoints} that creates a PDF plot of all the data.
This is illustrated in Figure \ref{fig:uqSanityCheck} for an MPI ping-pong benchmark.
Here the entire range of the parameter sweep is shown in red lines for the simulator values.
The range of experimental values for each output is also shown.
In this case, the parameter sweep covers all the experimental outputs suggesting that we can reproduce the experiments.

\begin{figure}
\includegraphics{figures/uqSanity.pdf}
\caption{Sanity check plot showing the parameter sweep data (red lines) against the experimental outputs (blue dots) for an MPI ping-pong benchmark}
\label{fig:uqSanityCheck}
\end{figure}

\section{Advanced Usage: Running Surrogate Construction and Sensitivity Analysis By Yourself}
Running the UQ analysis is involved. Help is available by contacting us at \url{sst-macro-help@sandia.gov}.
Documentation pending...

%\section{Applications/Capabilities}
%\label{sec:uqapp}
%
%\subsection{Forward UQ: uncertainty propagation and global sensitivity analysis}
%\label{subsec:fuq}
%
%The main technique we employ for forward UQ is the spectral Polynomial Chaos expansions (PCEs).
%A PCE for a given model allows for a) efficient uncertainty propagation, b) very fast global sensitivity analysis, and
%c) cheap surrogate model construction that can replace the original model in sampling-intensive studies such as calibration,
%optimization, or, generally, inverse UQ.
%
%\subsubsection{Generic workflow:}
%
%A set of scripts that illustrate the essential forward UQ tasks is located in  \texttt{examples\_cpp/uq\_surr}.
%To enable running all scripts one should set an environment variable \texttt{UQTK\_SRC} that points to the location of UQTk.
%
%\begin{ShellCmd}
%setenv UQTK_SRC location/of/uqtk/in/your/computer
%\end{ShellCmd}
%
%
%A generic workflow consists of 4 steps:
%\begin{enumerate}
%\item Generate parameter samples to run the forward model at, for PC construction and validation, \texttt{gen\_sam.x}
%\begin{ShellCmd}
%gen_sam.x <domain_file> <sampling_type(Q/U)> <N_samples> <N_val>
%\end{ShellCmd}
%The list of arguments:
%\subitem \emph{domain\_file}: A file with \bgmth d \endmth rows and 2 columns. \bgmth d \endmth is the total number of parameters being explored.
%           The two columns are the lower and upper bound of the corresponding parameter.
%\subitem \emph{sampling\_type}: Q (Quadrature) or U (uniformly random). Note that currently in this script set, only Q is supported for further PCE generation.
%\subitem \emph{N\_samples}: Number of samples used for training, i.e. for building PCE.
%\subitem \emph{N\_val}:  Number of random samples generated for PCE validation. This can be set to 0 to skip validation.
%
%\item Run the black-box model, \texttt{model.x}
%\begin{ShellCmd}
%model.x
%\end{ShellCmd}
%This is a black-box model that takes no arguments. However, it expects two input files mparam.dat and minput.dat, and returns the function evaluations in the output file moutput.dat.
%\subitem \emph{mparam.dat}: a single column $d\times$1 of the parameters of interest, where d is the number of parameters
%\subitem \emph{minput.dat}: controllable input in a matrix form, $N$$\times$$k$, where $k$ is the number of controllable parameters and $N$ is the number of values or model observables.
%\subitem \emph{moutput.dat}: the model output in a column format $N$$\times$1.
%
%This is the file that needs to be modified/provided by the user according to the model under study. Currently, a simple function $y=Ae^{Bx}+2Bx$ is implemented, where $A$ and $B$ are the parameters (mparam.dat) and $x$ is the single controllable input parameter (minput.dat). A user-created \texttt{model.x} should accept input files minput.dat and mparam.dat as described above, and it should produce an output file moutput.dat with the formats described above,
%
%\item Obtain PCE for the model, \texttt{uq\_surr.x}
%\begin{ShellCmd}
%uq_surr.x <domain_file> <sampling_type(Q/U)> <N_samples> <N_val> \
%		<P_order> <moutput_surr_filename> <moutput_val_filename>
%\end{ShellCmd}
%
%The first four arguments coincide with those from \texttt{gen\_sam.x}, the rest of the arguments are:
%\subitem \emph{P\_order}: the PCE surrogate order. Polynomial series is truncated according to the total order.
%\subitem \emph{moutput\_surr\_filename}: model output file resulting from running \texttt{model.x} on training samples.
%\subitem \emph{moutput\_val\_filename}: model output file resulting from running \texttt{model.x} on validation samples.
%
%\item Postprocess, e.g. global sensitivity analysis, \texttt{pp\_sens.x}
%\begin{ShellCmd}
%pp_sens.x
%\end{ShellCmd}
%
%The current implementation of the post processing script \texttt{pp\_sens.x} takes no arguments. It expects the presence of a PCE information file pccf\_all.dat, which is one of the outcomes of \texttt{uq\_surr.x}. The final global sensitivity results are saved in the \inlineshell{allsens.dat} file of dimensions $N$$\times$$d$, where each row corresponds to a single value for the controllable input (number of controllable inputs = N), and each column corresponds to the sensitivity index of a parameter (number of parameters = d).\\
%
%\medskip
%
%Note that one can run the model \texttt{model.x} in an \emph{online} regime by using the keyword "M" instead of filenames in
%\begin{ShellCmd}
%uq_surr.x <domain_file> <sampling_type(Q/U)> <N_samples> <N_val> <P_order> M M
%\end{ShellCmd}
%that effectively incorporates the steps 1-3 above.
%
%\subsubsection{Simple Example:}
%
%The script \texttt{example.x} incorporates the full workflow above for a test function $y=Ae^{Bx}+2Bx$. Try
%\begin{ShellCmd}
%example.x online
%\end{ShellCmd}
%which produces, in a newly created folder \texttt{test}, the sensitivity file \inlineshell{allsens.dat} with sensitivity indices with respect to $A$ and $B$ for all values of controllable input $x$.
%
%
%
%\end{enumerate}
%
%
%\subsubsection{How Forward UQ applies to \sstmacro}
%
%In the workflow described above, \sstmacro would replace the black-box simple model given by the equation, and \sstmacro parameters of interest would replace $A$ and $B$.   Note that while
%we could explore the entire \sstmacro parameter space using this workflow, the higher the dimensionality of the space the more time process takes, so we would also want to narrow it down to the most important parameters, usually by reasoning, inspection, or simple experimentation.
%Also note that running an \sstmacro simulation can be considerably more expensive than evaluating an
%analytical model, which is why we typically construct a \textit{surrogate}, or an arbitrarily-complex polynomial that can approximate performance given by \sstmacro.
%
%While the above workflow must currently be manually applied to \sstmacro data, we are working on automating this process and coming up with tutorials explaining how it is done.
%
%\subsection{Inverse UQ: parameter calibration and model validation}
%\label{subsec:iuq}
%
%UQTk relies on Bayesian inference methods for model parameter calibration. Model validation is a direct result of calibration
%postprocessing. Indeed, a model is considered validated if the calibrated model parameters and the associated uncertainties can explain/predict available data well.
%The library \texttt{uqtkmcmc} allows implementation of Bayesian calibration using Markov chain Monte Carlo (MCMC) methods. The MCMC technique essentially
%searches the parameter space and compares model results with available data. Note that each parameter sample invokes a model evaluation, and often MCMC requires
%many samples for properly estimating the uncertainties. In such cases, the full model, as a black-box, will be replaced by its surrogate, again as a black-box model, that is constructed by the forward UQ techniques described in Subsection~\ref{subsec:fuq}.


\hypertarget{classIir_1_1CascadeStages}{}\doxysubsection{Iir\+::Cascade\+Stages$<$ Max\+Stages, State\+Type $>$ Class Template Reference}
\label{classIir_1_1CascadeStages}\index{Iir::CascadeStages$<$ MaxStages, StateType $>$@{Iir::CascadeStages$<$ MaxStages, StateType $>$}}

{\ttfamily \#include $<$Cascade.\+h$>$}

\doxysubsubsection*{Public Member Functions}
\begin{DoxyCompactItemize}
\item
void \mbox{\hyperlink{classIir_1_1CascadeStages_ae5253fde0be7ccfa459a3f70fe8e3e31}{reset}} ()
\item
void \mbox{\hyperlink{classIir_1_1CascadeStages_a56d24da4cf09f898b534b1b05578244d}{setup}} (const double(\&sos\+Coefficients)\mbox{[}Max\+Stages\mbox{]}\mbox{[}6\mbox{]})
\item
{\footnotesize template$<$typename Sample $>$ }\\Sample \mbox{\hyperlink{classIir_1_1CascadeStages_aa18e9abcaac65fd21be31ee859add3bb}{filter}} (const Sample in)
\item
const \mbox{\hyperlink{structIir_1_1Cascade_1_1Storage}{Cascade\+::\+Storage}} \mbox{\hyperlink{classIir_1_1CascadeStages_a034a9be8ae590b814c8499898a93987a}{get\+Cascade\+Storage}} ()
\end{DoxyCompactItemize}

\doxysubsubsection{Detailed Description}
\subsubsection*{template$<$int Max\+Stages, class State\+Type$>$\newline
class Iir\+::\+Cascade\+Stages$<$ Max\+Stages, State\+Type $>$}

Storage for \mbox{\hyperlink{classIir_1_1Cascade}{Cascade}}\+: This holds a chain of 2nd order filters with its coefficients.

\doxysubsubsection{Member Function Documentation}
\mbox{\Hypertarget{classIir_1_1CascadeStages_aa18e9abcaac65fd21be31ee859add3bb}\label{classIir_1_1CascadeStages_aa18e9abcaac65fd21be31ee859add3bb}}
\index{Iir::CascadeStages$<$ MaxStages, StateType $>$@{Iir::CascadeStages$<$ MaxStages, StateType $>$}!filter@{filter}}
\index{filter@{filter}!Iir::CascadeStages$<$ MaxStages, StateType $>$@{Iir::CascadeStages$<$ MaxStages, StateType $>$}}
\doxyparagraph{\texorpdfstring{filter()}{filter()}}
{\footnotesize\ttfamily template$<$int Max\+Stages, class State\+Type $>$ \\
template$<$typename Sample $>$ \\
Sample \mbox{\hyperlink{classIir_1_1CascadeStages}{Iir\+::\+Cascade\+Stages}}$<$ Max\+Stages, State\+Type $>$\+::filter (\begin{DoxyParamCaption}\item[{const Sample}]{in }\end{DoxyParamCaption})\hspace{0.3cm}{\ttfamily [inline]}}

Filters one sample through the whole chain of biquads and return the result
\begin{DoxyParams}{Parameters}
{\em in} & Sample to be filtered \\
\hline
\end{DoxyParams}
\begin{DoxyReturn}{Returns}
filtered sample
\end{DoxyReturn}
\mbox{\Hypertarget{classIir_1_1CascadeStages_a034a9be8ae590b814c8499898a93987a}\label{classIir_1_1CascadeStages_a034a9be8ae590b814c8499898a93987a}}
\index{Iir::CascadeStages$<$ MaxStages, StateType $>$@{Iir::CascadeStages$<$ MaxStages, StateType $>$}!getCascadeStorage@{getCascadeStorage}}
\index{getCascadeStorage@{getCascadeStorage}!Iir::CascadeStages$<$ MaxStages, StateType $>$@{Iir::CascadeStages$<$ MaxStages, StateType $>$}}
\doxyparagraph{\texorpdfstring{getCascadeStorage()}{getCascadeStorage()}}
{\footnotesize\ttfamily template$<$int Max\+Stages, class State\+Type $>$ \\
const \mbox{\hyperlink{structIir_1_1Cascade_1_1Storage}{Cascade\+::\+Storage}} \mbox{\hyperlink{classIir_1_1CascadeStages}{Iir\+::\+Cascade\+Stages}}$<$ Max\+Stages, State\+Type $>$\+::get\+Cascade\+Storage (\begin{DoxyParamCaption}{ }\end{DoxyParamCaption})\hspace{0.3cm}{\ttfamily [inline]}}

Returns the coefficients of the entire \mbox{\hyperlink{classIir_1_1Biquad}{Biquad}} chain \mbox{\Hypertarget{classIir_1_1CascadeStages_ae5253fde0be7ccfa459a3f70fe8e3e31}\label{classIir_1_1CascadeStages_ae5253fde0be7ccfa459a3f70fe8e3e31}}
\index{Iir::CascadeStages$<$ MaxStages, StateType $>$@{Iir::CascadeStages$<$ MaxStages, StateType $>$}!reset@{reset}}
\index{reset@{reset}!Iir::CascadeStages$<$ MaxStages, StateType $>$@{Iir::CascadeStages$<$ MaxStages, StateType $>$}}
\doxyparagraph{\texorpdfstring{reset()}{reset()}}
{\footnotesize\ttfamily template$<$int Max\+Stages, class State\+Type $>$ \\
void \mbox{\hyperlink{classIir_1_1CascadeStages}{Iir\+::\+Cascade\+Stages}}$<$ Max\+Stages, State\+Type $>$\+::reset (\begin{DoxyParamCaption}{ }\end{DoxyParamCaption})\hspace{0.3cm}{\ttfamily [inline]}}

Resets all biquads (i.\+e. the delay lines but not the coefficients) \mbox{\Hypertarget{classIir_1_1CascadeStages_a56d24da4cf09f898b534b1b05578244d}\label{classIir_1_1CascadeStages_a56d24da4cf09f898b534b1b05578244d}}
\index{Iir::CascadeStages$<$ MaxStages, StateType $>$@{Iir::CascadeStages$<$ MaxStages, StateType $>$}!setup@{setup}}
\index{setup@{setup}!Iir::CascadeStages$<$ MaxStages, StateType $>$@{Iir::CascadeStages$<$ MaxStages, StateType $>$}}
\doxyparagraph{\texorpdfstring{setup()}{setup()}}
{\footnotesize\ttfamily template$<$int Max\+Stages, class State\+Type $>$ \\
void \mbox{\hyperlink{classIir_1_1CascadeStages}{Iir\+::\+Cascade\+Stages}}$<$ Max\+Stages, State\+Type $>$\+::setup (\begin{DoxyParamCaption}\item[{const double(\&)}]{sos\+Coefficients\mbox{[}\+Max\+Stages\mbox{]}\mbox{[}6\mbox{]} }\end{DoxyParamCaption})\hspace{0.3cm}{\ttfamily [inline]}}

Sets the coefficients of the whole chain of biquads.
\begin{DoxyParams}{Parameters}
{\em sos\+Coefficients} & 2D array in Python style sos ordering\+: 0-\/2\+: F\+IR, 3-\/5\+: I\+IR coeff. \\
\hline
\end{DoxyParams}

The documentation for this class was generated from the following file\+:\begin{DoxyCompactItemize}
\item
iir/Cascade.\+h\end{DoxyCompactItemize}


\documentclass[a4paper,11pt]{article}
\usepackage{a4wide}
\usepackage[utf8]{inputenc}
\usepackage{amssymb}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{enumerate}
\usepackage{fancyhdr}
\usepackage{array}
%\usepackage{./include/matrices}
\usepackage{graphicx}
%\usepackage{pictex}
\pagestyle{fancy}
\begin{document}
\renewcommand{\vec}[1]{\ensuremath{\underline{\mathbf{#1}}}}
% Equal sign with hat on top:
\newcommand{\corresponds}{\ensuremath{\widehat{=}}}

\section{fig 1 - handwritten page 2}
\[\substack{	\text{estimate of the density} \\
		\text{at a given point } \vec{x}}
\]
observations

\section{fig 2 - handwritten page 2}
Gaussian kernel \\\\
histogram kernel\\\\
$H$\\\\
$u$

\section{fig 3 - handwritten page 4}
true density \\\\
$P$\\\\
$\widehat{P}$
\[ \substack{ 	\text{estimated density} \\
		\text{(optimal w.r.t } E^T \text{)} }
\]

\section{fig 4 - handwritten page 5}
test data \\\\
model density I \\\\
model density II

\section{fig 5 - handwritten page 8}
Gauss\\\\
$\vec{w}^*$ \\\\
$\widehat{\vec{w}}$\\\\
\[ \substack{ 	\text{width}^2 \text{ (variance) given} \\
		\text{by Fisher information matrix} \\
		\text{(} \leadsto \text{error measure for }
			\widehat{\vec{w}} \text{)}}
\]

\end{document}