\chapter{How Cameras Work}

Let's say it is a sunny day and you are standing in field a few meters
from a cow. You use the camera on your phone to take a picture of the
cow. How does that whole process work?

\section{The Light That Shines On the Cow}

The sun is a sphere of hot gas. About 70\% of the gas is
hydrogen. About 28\% is helium. There's also a little carbon, nitroge,
and oxygen.

Gradually, the sun is converting hydrogen into helium through a
process known as ``nuclear fusion''. (We will talk more about nuclear
fusion in a later chapter.) A lot of heat is created in this
process. The heat makes the gases glow.

How does heat make things glow? The heat pushes the electrons into
higher orbitals.  When the fall back down to a lower orbital, they
release a photon of energy, which travels away from the atam as an
electromagnetic wave.

Heat isn't the only way to push the electrons into a higher
orbital. For example, a flourescent lightbulb is filled with gas.
When we pass electricity through the gas, its electrons are moved to a
higher orbital.  When they fall, light is created.

What is the frequency of the wave that the photon travels on?
Depending on what orbital it falls from and how far it falls, the
photon created has different amounts of energy. The amount of energy
determines the frequency of the electromagnetic wave.

\begin{mdframed}[style=important, frametitle={Formula for enegy of a photon}]

If you want to know the amount of energy $E$ in a photon, here is the formula:

$$E = \frac{h c}{\lambda}$$

where $c$ is the speed of light, $\lambda$ is the wavelength of the
electromagnetic wave, and $h$ Planck's constant: $6.63 \times 10^{-34} m^2 kg/s$

For example, a red laser light has a wavelength of about 630 nm. So the energy in each photon is:

$$\frac{(300 \times 10^6) (6.63 \times 10^{-34})}{630 \times 10^{-9}} = 3.1 \times 10^{-19} \text{ joules}$$

\end{mdframed}

In the sun, there are several kinds of molecules and each has a few
different orbitals that the electrons can live in.  Thus, the light
coming from the sun is made up of electromagnetic waves of many
different frequencies.

We can see some of these frequencies as different colors, but some are
invisible to humans, for example ultraviolet and infrared.

\section{Light Hits the Cow}

When these photons from the sun hit the cow, the hide and hairs of the
cow will absorb some of the photons. These photons will become heat
and make the cow feel warm.  Some of the photons will not be absorbed
-- they will leave the cow.  When you say ``I see the cow,'' what you are
really saying is ``I see some photons that were not absorbed by the cow.''

Different materials absorb different amounts of each wavelength. A
plant, for example, absorbs large percentage of all blue and red
photons that hit it, but it absorbs only a small percentage of the
green photons that hit it.  Thus we say ``That plant is green.''

White things absorb very small percentages of photons of any visible
wavelength.  Black things absorb very \emph{large} percentages of
photons of any visible wavelength.

Before we go on, let's review: The sun creates photons that travel as
electromagnetic waves of assorted wavelengths to the cow.  Many of
those photons are absorbed, but some are not.  Some of those photons
that are not absorbed go into the lens of our camera.

\section{Pinhole camera}

The simplest cameras have no lenses. They are just a box.  The box has
a tiny hole that allows photons to enter.  The side of the box
opposite the hole is flat and covered with film or some other
photo-sensitive material.

The photons entering the box continue in the same direction they were
going when they passed through the hole.  Thus, the photons that
entered from high, hit the back wall low.  The photons that came from
the left, hit the back wall on the right. Thus the image is projected
onto the back wall rotated 180 degrees: What was up is down, what was
on the left is on the right.

FIXME: picture here

\begin{Exercise}[title={Height of the image}, label=image_height]

Let's say that that the pinhole is exactly the same height as the
shoulder of the cow and that the shoulder is directly above one hoof.
Than the pinhole, the shoulder, and the hoof form a right triangle.

Now, let's say that the camera is being held perpendicular to the
ground.  Now, the pinhole, the image of the shoulder, and the image of
the hoof on the back wall of the camera also form a right triangle.

These two triangles are similar.

The shoulder is 2 meters from the hoof.  The cow is standing 3 meters
from the camera.  The distance from the pinhole to the back wall of
the camera is 3 cm.  How tall is the image of the cow on the back wall
of the camera?

\end{Exercise}
\begin{Answer}[ref=image_height]

The two triangles are similar, one is 2 m and 3m.  The other is $x$ cm and 3 cm.

The image of the cow is 2 cm tall.

\end{Answer}

\section{Lenses}

Quick review: A photon leaves the sun in some random direction. It
travels 150 million km from the sun and hits a cow.  It is not
absorbed by the cow, and heads off in a new direction.  It passes
through the pinhole and hits the back wall of the camera.  That seems
incredibly improbable, right?

It actually is kind of improbable, especially if there isn't a lot of
light -- like you are taking the picture at dusk.  To increase the
odds, we added a \newterm{lens} to the camera.

If you focus a lens on a wall, and then you draw a dot on the
wall. The lens is designed such that all the photons from the dot that
hit the lens get redirected to the same spot on the back wall of the
camera -- regardless of which path it took to get to the lens.

FIXME: illustration here

Note that the image still gets flipped.  There is a \newterm{ focal
point } that all the photons pass through.

FIXME: illustration here

The distance from the lens to its focal point is called the lens's
\newterm{focal length}. Telephoto lenses, that let you take big
pictures of things that are far away, have long focal lengths.
Wide-angle lenses have short focal lengths.

\section{Sensors}

The camera on your phone has a sensor on the back wall of the
camera. The sensor is broken up into tiny rectangular regions called
pixels.  When you say a sensor is 6000 by 4000 pixels, we are saying
the sensor is a grid of 24,000,000 pixels: 6000 pixels wide and
4000 pixels tall.

Each pixel has three types of cavities that take in photos. One of the
cavities measures the amount of short wavelength light, like blues and
violets. One of the cavities measures the long wavelength light, like
reds and oranges. One of the cavities measures the intensity of
wavelengths in the middle, like greens.

Thus, if your camera has a resolution of $6000 \times 4000$, the image
is 72,000,000 numbers: Every one of the 24,000,000 pixels yeilds three
numbers: intensity of long wavelength, mid wavelength, and long
wavelength light. We call these numbers ``RGB'' for Red, Green, and
Blue.


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

\marginpar{Tuesday\\ 2020-4-21, \\ compiled \\ \today}

Now we have a dilemma: beauty versus pragmatism.

How do we provide a mass to the \(W\) vector boson?

% We could introduce an \(SU(2)\) symmetry.

As we were discussing, we could add a mass term and write
%
\begin{align}
\mathscr{L} = \mathscr{L} _{\text{Yang-Mills}} + M^2 W^{+}_{\mu } W^{\mu, -}
\,,
\end{align}
%
but this term \emph{brutally} breaks the symmetry.
This is explicit breaking of the symmetry.

However, if we do not break the symmetry we cannot reproduce the data\dots or can we?

\subsection{Spontaneous Symmetry Breaking}

We introduce \textbf{Spontaneous Symmetry Breaking}.
This is a phenomenon which is not exclusive to HEP: it happens in ferromagnets, for example.
They start off (above the Curie temperature) with the spins pointing in uniformly distributed directions: the situation is symmetric.
As we cool them, at a certain stage all the spins align.
We cannot predict the direction along which they will align (since the initial state is symmetric), but once they do the symmetry is \emph{spontaneously broken}.

Let us take the standard approach (also done in the Theoretical Physics course \cite[sec.\ 5.2]{tissinoTheoreticalPhysicsNotes2020}) introduce the Lagrangian of a complex scalar field \(\phi \):
%
\begin{align}
\mathscr{L} = \qty(\partial^{\mu  } \phi^{*}(x)) \qty(\partial_{\mu } \phi (x))
\underbrace{- \mu^2 \abs{\phi (x)}^2
- \lambda^{4} \abs{\phi (x)}^{4}}_{- V(\phi )}
\,,
\end{align}
%
and to find the ground state we can move to the Hamiltonian:
%
\begin{align}
\mathscr{H} = \pi(x) \phi (x) - \mathscr{L}
\,.
\end{align}

The parameter \(\lambda \) must be \(>0\), while \(\mu^2\) has no constraints.

It is a critical parameter: if \(\mu^2\) is positive we are in the symmetric phase of the system, and the vacuum is only \(\phi = 0\): the VEV is \(\bra{0} \phi \ket{0} = 0\).

If, on the other hand, \(\mu^2\) is negative we transition to a new phase which is not symmetric: the vacuum becomes a whole circle, whose VEV is \(v = \sqrt{- \mu^2 / 2 \lambda }\). The whole region parametrized as \(v e^{i \theta }\), with \(\theta \in \mathbb{R}\), provides equivalent vacua:
a specific ground state is not symmetric under the whole symmetry of the Lagrangian.

Why do we only have terms in \(\phi^2\) and \(\phi^{4}\)? we basically constructed the simplest potential which has the properties we want.

If \(\mu^2>0\) we can perturb around the state without the quartic term, which is described by the KG equation.

If, instead, we want to perturb around a vacuum in the \(\mu^2<0\) case we need to distinguish two directions, since the Hessian of the potential has two different eigenvalues, one positive and one equal to zero. We parametrize
%
\begin{align}
\phi = \frac{1}{\sqrt{2}} \qty(v + \sigma (x) + i\eta (x))
\,,
\end{align}
%
where \(\sigma \) and \(\eta \) are both real.

The Lagrangian can then be rewritten as
%
\begin{align}
\mathscr{L} = \frac{1}{2} \partial^{\mu } \sigma \partial_{\mu } \sigma
+ \frac{1}{2} \partial^{\mu } \eta \partial_{\mu } \eta
+ 2 \lambda v^2 \frac{1}{2} \sigma^2
- \frac{\lambda}{4} \qty(\sigma^2 + \eta^2)^2
- \lambda v \sigma \qty(\sigma^2 + \eta^2)
\,,
\end{align}
%
so we have two real fields, one massive  (\(\sigma \)) and one massless (\(\eta \)). The massless field is called a \textbf{Goldstone boson}.

If we compute the VEV of \(\phi \) in this configuration we get     \(v / \sqrt{2 }\).

In general, the Golstone theorem states that for each broken symmetry generator we get a massless boson.

It seems that instead of solving the problem of our massless gauge bosons we have created another problem, predicting more massless particles; but in fact our two problems solve each other.

We must break a different symmetry, though: a gauge local symmetry, instead of a global one.
If we explicitly break a \(U(1)\) global symmetry, we have a Goldstone boson.
If we break a \(U(1)\) local symmetry, instead, we get a massless vector boson and a massless scalar.
This spontaneous breaking of local gauge symmetry is the \textbf{Higgs mechanism}.

\subsubsection{SQED Higgs mechanism}

We will see this explicitly, with the breaking of the scalar-QED \(U(1)\) symmetry: let us consider a Lagrangian
%
\begin{align}
\mathscr{L} = \qty(\DD^{\mu } \phi )^{*} \DD_{\mu } \phi
- \mu^2 \abs{\phi}^2 - \lambda \abs{\phi }^4
- \frac{1}{4} F^{\mu \nu } F_{\mu \nu }
\,,
\end{align}
%
where \(\DD_{\mu } = \partial_{\mu } + iq A_{\mu} \).
This is similar to a Lagrangian describing a fermion, but we substitute it with a complex scalar field with charge \(q\).

This Lagrangian has a \(U(1)\) gauge symmetry, whose action is
%
\begin{align}
\phi &\to e^{-iq \alpha (x)} \phi \\
\phi^{*} &\to e^{iq \alpha (x)} \phi^{*} \\
A_{\mu } &\to A_{\mu } + \partial_{\mu } \alpha
\,.
\end{align}

If \(\mu^2>0\) we have no issues: the only minimum is the global one at \(\phi = A_{\mu } = 0\). This is the only configuration which is Lorentz invariant: any other vector would define a direction, breaking Lorentz symmetry.

The last point also holds if \(\mu^2 < 0\); so the possible vacua are those defined as \(\phi = v e^{i \theta } / \sqrt{2}\) and \(A^{\mu } = 0 \).
Let us perturb as we did before: if we define
%
\begin{align}
\phi (x) = \frac{1}{\sqrt{2}} \qty(v + \sigma (x) + i \eta (x))
\,,
\end{align}
%
the Lagrangian can be rewritten as
%
\begin{align}
\begin{split}
\mathscr{L} &= \frac{1}{2} \partial^{\mu } \sigma \partial_{\mu }\sigma
- \frac{1}{2} (2 \lambda v^2) \sigma^2(x)
- \frac{1}{4} F^{\mu \nu } F_{\mu \nu } \\
&\phantom{=}\
+ \frac{1}{2} (q v)^2 A_{\mu } A^{\mu }
+ \frac{1}{2} \partial^{\mu }\eta \partial_{\mu } \eta
+ qv A^{\mu } \partial_{\mu } \eta
+ \text{higher-order interactions}
\,.
\end{split}
\end{align}

This Lagrangian describes a real scalar \(\sigma \) with mass \(\sqrt{2 \lambda v^2}\); a massless real scalar \(\eta \); a massive vector boson and the interactions between them.

Let us count degrees of freedom: we started with a complex scalar \(\phi \) (2 dof) and a massless vector (2 dof); now we have two real scalars (1 dof each) and a massive vector (3 dof): we have gone from a total of four to a total of five!
So, there must be an unphysical field between these.

In fact, we can do a gauge transformation (going to the \emph{unitary gauge}) so that \(\phi \) is real everywhere: this removes the need for \(\eta \).
After this manipulation, the Lagrangian will read
%
\begin{align}
\begin{split}
\mathscr{L} &= \frac{1}{2} \partial^{\mu } \sigma \partial_{\mu } \sigma
- \frac{1}{2} (2 \lambda v^2) \sigma^2
- \frac{1}{4} F_{\mu \nu } F^{\mu \nu } \\
&\phantom{=}\
+ \frac{1}{2} (qv)^2 A_{\mu} A^{\mu }
+ \text{higher-order interactions}
\,,
\end{split}
\end{align}
%
so we are left with a massive scalar \(\sigma \) (1 dof) and a massive vector \(A_{\mu } \) (3 dof): the total is 4 again!

It is a ``transmutation'' of degrees of freedom: one dof has gone from the scalar to the vector making it massive.

This is the \textbf{Higgs mechanism}.

% The wonderful thing is that the two dof of the massless vector ad the single degree of freedom of the massless scalar couple to give a massive vector with three degrees of freedom.

\end{document}


\documentclass[12pt]{cdblatex}
\usepackage{bssn-eqtns}

\begin{document}

\section*{PhysRevD.62.044034 equation (20)}

\begin{cadabra}
   from shared import *
   import cdblib

   jsonfile = 'bssn-eqtns-20.json'
   cdblib.create (jsonfile)

   # --------------------------------------------------------------------------

   DGiBarDt := \partial_{t}{GammaBar^{i}}.                 # cdb(eq20.00,DGiBarDt)
   DGiBarDt := - 2 ABar^{i j} \partial_{j}{N}
               + 2 N (  GammaBar^{i}_{j k} ABar^{k j}
                      - (2/3) gBar^{i j} \partial_{j}{trK}
                      + 6 ABar^{i j} \partial_{j}{\phi}).  # cdb(eq20.01,DGiBarDt)

   substitute   (DGiBarDt,defGammaBarU)                    # cdb(eq20.02,DGiBarDt)

   distribute   (DGiBarDt)
   DGiBarDt = product_sort (DGiBarDt)                      # cdb(eq20.03,DGiBarDt)

   canonicalise (DGiBarDt)                                 # cdb(eq20.04,DGiBarDt)
                                                           # cdb(eq20.99,DGiBarDt)

   cdblib.put ('DGiBarDt',DGiBarDt,jsonfile)
\end{cadabra}

\begin{dgroup*}
   \begin{dmath*}
      \cdb{eq20.00} = \Cdb*{eq20.01}
                    = \Cdb*{eq20.02}
                    = \Cdb*{eq20.03}
   \end{dmath*}
\end{dgroup*}

\end{document}


\documentclass[twoside]{MATH77}
\usepackage{multicol}
\usepackage[fleqn,reqno,centertags]{amsmath}
\begin{document}
\begmath 19.4  Converting Codes to Different Versions

\silentfootnote{$^\copyright$1997 Calif. Inst. of Technology, \thisyear \ Math \`a la Carte, Inc.}

\subsection{Purpose}

This program, {\tt m77con}, converts codes from one version to another.
It is used to convert between different precisions, and to support the
special comments used in some of the Fortran codes for input to a program
that converts programs from Fortran to C.  Support is provided for
precision greater than double for systems that support such a feature.
Support is provided for conversion between real programs and integer or
complex versions of a program, and also partial double precision and
partial quadruple precision.  Most MATH77 codes contain the comments only
for conversion between the single and double precision cases.  Although
designed for use with MATH77 codes, {\tt m77con} could be used in other
applications that want a portable means to support multiple versions.  Any
version of a code can be used as input to {\tt m77con} for the purpose of
getting another version.

\subsection{Usage}

    One uses this program by creating a control file named {\tt
m77job}, and executing the program {\tt m77con} from the command
line.  The first part of this section describes the control file which
defines what version is desired.  The second part describes the
comments in the code which indicate how different versions are to be
obtained.

\subsubsection{Transforming an Instrumented Code}

In the descriptions below, items in brackets are optional; $L_i$ is
used for letters (frequently the first letter in the name of a
program, which indicates the precision); and $T_i$ is used for
letters associated with types. Types supported include: S, D, Q, I,
C, Z, and W, which are used for Single precision, Double precision,
Quadruple precision (or at least some  precision greater than
double), Integer, Complex, double precision complex, and quadruple
precision complex respectively.

``C...'' is a comment and can appear anywhere in the control file.  A
comment of the form ``C$>>$yyyy$-$mm$-$dd...'' is treated as a special
case.  It inserts a date stamp in the file being processed, which is
used to track changes in MATH77 codes. Details on this can be found in
the code listing for {\tt m77con}.

``MAKE $L_{out}$ [with type $T_{out}$] [from $L_{in}$ [with type
$T_{in}$]]'' is used to define a letter in the names of the output
and input files and types associated with these files.  $L_{out}$ is
a letter used in output file names.  $T_{out}$ is the type for the
output file. If $T_{out}$ is not given it is assumed to be $L_{out}$
if $L_{out}$ is an allowed type, is assumed to be S or D, for
$L_{out}$ =  P or X respectively, and otherwise an error results.  (P
is assumed to be used for partial double precision, and X for partial
quadruple precision.)  $L_{in}$ and $T_{in}$ are defined as for
$L_{out}$ and $T_{out}$, except they apply to input files.  If the
``from'' clause is missing, $L_{in}$ is D, except when $L_{out}$ is
D, in which case $L_{in}$ is S. The case of letters is not
significant, except for $L_{out}$.  The case used for $L_{out}$
determines the case used when substituting $L_{out}$ or $L_{in}$ into
a file name, and thus the case is significant on systems where case
is significant in a file name.

``$T$ Defined by: $L_{exp}$, {\em keyword}, {\em type\_conv}, {\em
mach\_const}\/''\newline
``$T$ Defined by: {\em keyword}, {\em type\_conv},
{\em conj}, {\em imag\_part}\/''\newline
One of these lines is needed only if the input or output code makes
use of a nonstandard type, namely, Q, Z, or W.  Note that W makes use
of Q, and thus if it is used, Q must also be defined.  The first type
of line is used to define real (as opposed to complex) types.  $L_{exp}$
is the letter used to define the exponent part of floating point
constants, {\em keyword} is the text used to declare a variable of
type $T$, {\em type\_conv} is the name of the function used for type
conversion to type $T$, {\em mach\_const} is the name of the function
used for getting machine constants, {\em conj} and {\em imag\_part}
are the functions used to conjugate or get the imaginary part of a
complex expression, respectively.  The standard S, D, and C types are
initialized as if one had input:\newline ``S Defined by: E, real,
real, r1mach'',\newline ``D Defined by: D, double precision, dble,
d1mach'', and \newline ``C Defined by: complex, cmplx, conjg, aimag''

Note that at most one embedded blank is allowed inside {\em keyword},
and if such a blank is desired it must be included on this line.
Internally, `I' defines {\em keyword} as ``integer'', and {\em
type\_conv} as ``int''.

``VERIFY path'' if present will compare the lines of the result files
with lines in the files of the same name as the result files preceded
by ``path'', and when lines are different, both lines will be printed.
The text in ``path'' is taken exactly as given, and is considered
terminated by either a blank or an end of line.  This comparison is
not sensitive to changes in the special comment lines described in
the following subsection, or to differences in the number of
blanks.

``SET $A_1$, $A_2$, ... $A_n$'' is used to set values for the
metavariables defined by the assignments $A_i$.  These assignments, which
sometimes are necessary to get the version of a code desired, and the
metavariables set by these assignments, are described in the following
subsection.  One can have any number of ``SET...'' lines.

``STOP ...'' acts like an end of file, i.e. no more lines are read in
the control file.

``FILE {\em name}[[,] {\em ext}]'' is used to specify the name of a file
to be processed.  A ``?'' in name may be used to parameterize the name if
desired.  $L_{in}$ is substituted for the ``?'' (if any) and a file of
this name is processed as the input file.  Then $L_{out}$ is substituted
for ``?'' to obtain the name of the output file.  If the ``,~{\em ext}\/''
is present and one of the first two characters in {\em ext} is ``.'' this
name is further modified by searching backward from the end of ``{\em
name}\/'' looking for the first character in ``{\em ext}\/''.  When this
character is found, this character and the following characters in {\em
name} are replaced by ``{\em ext}\/''.  If the ``,~{\em ext} is present
and neither of the first two characters is a ``.'', {\em ext} is used as
the name of the output file.  The input and output files can have the same
name.  If the ``?'' is missing, there is no need to have had a ``MAKE...''
line.  Any characters except ``,'' can appear in ``{\em name}\/'' or
``{\em ext}\/'', as long as the results will serve as valid file names.
Examples and Remarks, below, gives samples of FILE statements.

Processing a ``FILE...'' line involves carrying out conversions on
the specified input file and placing the result in the output file.
If a ``VERIFY...'' line is present, the output file will be compared
with the file specified there.  After processing a ``FILE ...'' line,
the next line from the control file, {\tt m77job}, is read, and
actions are taken as requested there.  All metavariables defined in
previous SET instructions become undefined if there is a new SET
instruction; otherwise the old values are kept.

\subsubsection{Instrumenting a Code}

We use the notation:

\begin{tabular}{l@{ }l@{ }ll}
$L$,&$L_1$,&... $L_i$ & Letters\newline\\
$T$,&$T_1$,&... $T_i$ & Letters used to denote types\newline\\
$I$,&$I_1$,&... $I_i$ & Integer constants\newline\\
$V$,&$V_1$,&... $V_i$ & Metavariables\newline\\
$E$,&$E_1$,&... $E_i$ & Expressions\newline\\
$A$,&$A_1$,&... $A_i$ & Assignments\newline\\
\end{tabular}

The types are: S, D, Q, I, C, Z, and W, which are used for Single
precision, Double precision, Quadruple precision (or at least some
precision greater than double), Integer, Complex, double precision
complex, and quadruple precision complex respectively.  An ``$L$''
equal to one of these letters is used for a code of the corresponding
type.  Other letters are used for mixtures of types.  In particular,
P (Partial double) is used for a code that uses some D in a code that
is primarily S (perhaps to save on storage), and X (eXtended) is used
for a code that is primarily in D, but uses some Q.  No other
precisions are supported.

There are integer, logical, and string metavariables and constants.
An integer constant is defined as in Fortran.  The logical constants
are .T.\, .F.\, .U.\, .D.\, .S.\, .I.\, and .C.\ Of course .T.\ is
always true, and .F.\ is false; .U.\ is undefined (see below); .D.\,
.S.\, and .I.\ have a value of .T.\ if the upper case of the letter
$L_{out}$ in a MAKE command matches the letter between the dots, has a
value of .F. if $L_{out}$ is defined but does not match, and otherwise
has the value .U.; and .C.\ has the value .T.\ if a version of the
code used as input to the Fortran to C converter is being generated,
and is .F.  otherwise.  Initially .C.\ =.F.; its value can be set to
.T.\ with the statement ``SET .C.'' in {\tt m77job}, and can be reset
to .F.\ with the statement ``SET $\sim $.C.''.  (With T=.T., F=.F.,
and U=.U., we have, U$|$F=.U., U$|$T=.T., U\&F=.F., U\&T=.U., $\sim
$U=.U.  If U is on either side of a relational operator, the result is
.U.)

A string is defined as an arbitrary sequence of characters enclosed by
either apostrophes ({\tt '}), or quotes ({\tt "}), has the same form as a
metavariable (see below), or is .X., .Y., or .N.\ \ \ .X.  gives the
string consisting of the letter used for floating point exponents in the
output, .Y.\ gives the string consisting of the letter $T_{out}$, and
.N.\ gives the string consisting of the letter $L_{out}$.  If a
logical value of a string is required by the context, a string has the
value .U.

A metavariable is any number of nonoperators, not all of which are
digits, and not one of the letters ``TFUXN'' preceded and followed by
a ``.''.  Metavariables once defined remain defined until the end of
the file. Those metavariables defined in {\tt m77job} remain defined
past the end of file, until the next ``SET...'' line read in {\tt
m77job}. Note that metavariables appear only in ``C++...'' lines
and in lines immediately following ``C++ Substitute for ...'' lines.

Expressions may use the following operators, all of which have the same
meaning and precedence as their Fortran counterparts.

\begin{tabular}{ll}
Arithmetic:&        + \hspace{8pt} $-$ \hspace{8pt} * \hspace{8pt} /
 \hspace{8pt} **\\
Relational:&        $<$ \hspace{8pt} $>$ \hspace{8pt} == \hspace{8pt} /=
 \hspace{8pt} $<=$ \hspace{8pt} $>=$\\
Alt. Relational:&         = \hspace{8pt} $\sim $=\\
Logical:&           $|$ (or) \hspace{8pt}  \& (and) \hspace{8pt} $\sim $ (not)\\
Concatenation:&     // \\
Grouping letters:&  $\{$ \hspace{8pt}  $\}$\\
Other:&             ( \hspace{8pt}  ) \hspace{8pt} ,\\
\end{tabular}

The ``$\{$'' and ``$\}$'' are used to define a special operand.  If
the letter $L_{out}$ from the ``MAKE...'' line, see ``Transforming an
Instrumented Code'' above, appears inside the \{...\}, then this
operand has the value true, and otherwise has the value false.  The
letters inside the \{...\} may optionally be separated by commas.
Thus \{SP\} is true if $L_{out}$ is either S or P, and is false
otherwise.

We recommend using ``=='' rather than ``='' in relational
expressions.  ``='' is allowed for compatibility with comments
written for an earlier processor. The first ``='' in an assignment
statement is part of the assignment statement, not part of an
expression.

An expression can be formed as one would expect using the operators
that are available.  A diagnostic is given if one tries to mix types
in a way that make no sense.  Integer and logical are converted to
strings when they appear as an operand of ``//''.

As assignment has the form: $V = E$, or simply $V$.  The latter form is
equivalent to writing $V$=.T.

Three kinds of comments in the source code initiate special processing by
the program.  (Not counting the ``C$<<$...'' comments which are used for
date stamps.) Those headed by ``C++'' are intended primarily to support
different versions of a program.  Those headed by ``C$--$'' are intended
primarily to support different precisions, which involves changing types in
Fortran statements.  Those headed by ``C\%\%'' are used to convert the
code to the form needed for the Fortran to C conversion program.  The
actions for ``C++...'' lines precede other actions, and thus a ``C++...''
line could result in turning off a ``C$--$...'' line.  Also, if there was
no ``MAKE...'' line, type conversion is turned off, and ``C$--$...'' lines
are simply treated like any other comments.  These comments allow either
case for the ``C'' and also allow an ``*'' in column one.

``C++...'' lines have the form:

\begin{tabular}{@{}l@{ }l@{ }l}
(1) & ``C++ & Code for $E$ is active''\\
(2) & ``C++ & Code for $E$ is inactive''\\
(3) & ``C++ & END''\\
(4) & ``C++ & Of next $I$ lines, only the first $E$ are active''\\
(5) & ``C++ & Default $A_1$, $A_2$, ... $A_i$'', or\\
    & ``C++L & Default $A_1$, $A_2$, ... $A_i$'', or\\
    & ``C++(E) & Default $A_1$, $A_2$, ... $A_i$''\\
(6) & ``C++ & Current has A''\\
(7) & ``C++ & Substitute for $V_1$, $V_2$, ... $V_i$ below''\\
(8) & ``C++ & Replace $A_1$, $A_2$, ... $A_i$''\\
(9) & ``C++ & [With first index $E_1$,]\\
    &       & Save data by elements if $E_2$''
\end{tabular}

A line of form (1) or (2) initiates a scope of applicability that is
terminated by the next line of form (1), (2), or (3).  In either case
(1) or (2), if $E$=.U., no change is made in this line or in the
lines in its scope.

In the case of (1), if $E$=.T. there is no change.  If $E$=.F.,
the word ``active'' is changed to ``inactive'' and in the following
scope, columns 1--71 are shifted to columns 2--72 and a C placed in
column 1.  An error message is printed if the original line was not
blank in column 72.  (Only the first 72 characters of input lines are
read.)

In the case of (2), if $E$=.F. there is no change.  If $E$=.T. the
word ``inactive'' is replaced by ``active'' and in the following
scope, columns 2--72 are copied to columns 1--71, and a blank placed
in column 72.

No other ``C++...'' line may appear between a line of type (1) or (2)
and the next line of type (1), (2), or (3).  No code changing action
can be active when the end of a Fortran program unit is reached.

Examples from AMACH of lines of type (1), (2) and (3) are,

\begin{verbatim}
c++ Code for SYS = IEEE is ACTIVE
...
c++ Code for SYS = AMDAHL is INACTIVE
C ...
c++   END
\end{verbatim}

In case (4), one must have $I$ (an integer constant) $>$ 0, and $E$
must have an integer value $ <= I$.  The following $I$ lines in the
code must be valid Fortran statements if column~1 is set to a blank
and there must be $I$ lines preceding the last line of the Fortran
program unit. This causes the action of storing a ` ' in column~1 of
the following $E$ lines, and then storing a `C' in column~1 for the
remaining $I - E$ lines (neither shifts the line).

An example from DIVA of using this feature is (the first two lines
given here are one line in the code):

\begin{verbatim}
c++ Of next 23 lines, only the first
                        KDIM+MAXORD are active
      data B(1)  / 5.00000...0D-1 /
      ...
      data B(22) / 1.97628...5D-3 /
C     data B(23) / 1.81159...2D-3 /
\end{verbatim}

In case (5) when no L or (E) is present each assignment, $A_i$, is
executed if and only if the $V_i$ on the left of the ``='' in the $A_i$ is
not already defined.  (Recall that if $A_i$ does not contain an ``=''
sign, it is as if it had the form ``$V_i$ = .T.''.)  $V_i$ may have been
defined either from a ``SET...'' line in {\tt m77job} or from an
earlier ``C++'' line.  When L is present, L must be a sequence of
letters and the assignments will be processed as described for the
case when no L is present if and only if the current $L_{out}$ matches
one of the letters in L.  When (E) is present, the line is processed as
above if E is a logical expression with the value .T., else the line rest
of the line is ignored.

The following example from DRDIVA illustrates defining a default
value for NDIG of 4 for type of ``S'' or ``P'', and a default value for NDIG
of 10 in other cases.  If NDIG has been set in {\tt m77job}, then
the value set there will be used.

\begin{verbatim}
c++SP Default NDIG = 4
c++  Default NDIG = 10
\end{verbatim}

In case (6), the A must have an ``='' sign.  If the $V$ on the left
side of the ``=''  in A is not defined this works just like a
``C++ Default A'' line.  If $V$ is defined, then the text on the
right of the ``='' is replaced by the current value of $V$.

The following line from AMACH shows that AMACH is currently
configured for SYS = IEEE.  If SYS is not set in {\tt m77job}, this
value for SYS will continue to be used.  Otherwise the new value will
replace the {\tt IEEE} on this line.

{\tt c++ CURRENT HAS SYS = IEEE}

In case (7), the following line is examined for each of the $V_i$'s in
turn.  If such a metavariable name is found followed by an ``='' sign, and
an integer value, the integer is replaced by the integer value of $V_i$.
If the ``='' sign is followed by a logical value, this value is replaced
by the corresponding Fortran logical constant for $V_i$.  A type mismatch
in either of these cases results in a diagnostic, with no change.  A
value of .U. in this case is treated as a mismatch.

The following from DRDIVA illustrates using this feature.

\begin{verbatim}
c++ Substitute for NDIG below
      parameter (NDIG = 10)
\end{verbatim}

In case (8), the left side of each $A_i$ must be a constant character
string, i.e. either {\tt '}xx...x{\tt '} or {\tt "}xx...x{\tt "}, and
the right side, $E_i$,  must be an expression that evaluates to a
string value.  Occurrences (case of letters must match) of the
``xx...x'' on the left of $A_i$ are replaced by the value for $E_i$.
The replacement is made on ``C++ Replace...'' lines, and other lines
not starting with ``C++''.  If this line precedes a ``C$--$...'' line
of type (1), see below, then the replacement applies starting with
the first line of the file else it applies starting with the current
line.

The following from DRDRAN illustrates this feature.

\begin{verbatim}
c++S Default NDIG = 6
c++  Default NDIG = 12
c++  Replace "f15.12" = "f"//NDIG+3//"."//NDIG
...
      print'(7x,i7,'',''i5,10x,f15.12)',K...
\end{verbatim}

Case (9) is intended primarily to avoid unnecessary mess in Fortran code
that would have too many continuation lines for a data statement in
Fortran when declared with a single array.  The C converter we are using
generates much better code when such data statements are declared with a
single array instead of a separate statement for each element.  $E_1$ must
be a integer expression, and $E_2$ must be logical.  If the part
containing $E_1$ is missing the action is as if $E_1$ were present with a
value of 1.  The data statement following this must contain exactly one
data item per line.  When $E_2$ = .T., the first line and every following
line that is either a continuation line, or is a data statement for the
same name, is changed (if necessary) to be a data statement for a single
element of the array.  The index used for the array element is $E_1$ for
the first data statement and is incremented by one for the following
statements.  If $E_1$ is .F.  the first data statement line uses only the
array name, and following lines that are either continuation lines, or
data statements for the same name are changed to be continue statements.
There is no limit on the number of continued lines.

The ``C$--$...'' lines have the form:

\begin{tabular}{@{}lll}
(1) & ``C$-$$-$$L$ & Replaces ``?'': $V_1$, $V_2$, ...''\\
(2) & ``C$-$$-$$T$ & (Type)Replaces ``?'': $V_1$, $V_2$, ...''\\
(3) & ``C$-$$-$\& & $v_1$, $v_2$, ...''\\
(4) & ``C$-$$-T$ & Next line special: $S_1$, $S_2$, ...''\\
(5) & ``C$-$$-$ & Begin mask code changes''\\
(6) & ``C$-$$-$ & End mask code changes''\\
\end {tabular}

At most one of (1) or (2) can occur in a file, and all lines of type
(3) must follow immediately after a (1) (2) or (3).  (No embedded
comments.) In case (1) $L$ denotes the value of $L_{out}$ for the
current version of the code.  (See the description of the ``MAKE...''
line in Usage above.) If $L$ = $L_{out}$, then no names are changed.
When $L=L_{in}$ the $L$ in this statement is replaced by $L_{out}$.
Each of the $V_i$, or $v_i$, must be Fortran names with one of the
letters replaced by a ``?''.  These names with the ``?''  replaced by
$L_{in}$ are searched for and replaced as described below, starting
at the beginning of the file.  A line of type (2) must follow
immediately after a line of type (1) or (3).  The action for this
kind of line is similar to that for type (1),  but with $L$,
$L_{out}$, and $L_{in}$, replaced by $T$, $T_{out}$, and $T_{in}$
respectively.

The following excerpt from DWCOMP illustrates lines of type (1) and
(3).

\begin{verbatim}
c--D replaces "?": ?WCOMP,?WATAN,...
c--&   ?WSQRT,?WEXP,?WSIN,?WCOS,...
\end{verbatim}

Case (4) is used to indicate either that something different from the
standard conversion is to be used on the next line, or that
conversion to or from integer or one of the complex types is allowed.
Conversions to or from integer types occur only on lines so marked.
For a conversion to or from a code corresponding to the first letter
of one of the pairs, (C, S), (Z, D), (W, Q), the conversion is done
as if the second letter applied, except for lines marked in this
manner.  $T$ indicates the type to assume for the input on the
following line. The $T$ is replaced by the value used for the type of
the output on the next line.  The $S_i$ is either a single $L_i$, or
an expression of the form $L_i$ $=>$ $T_i$. If $L_{out}$ is the same
as any of these $L_i$, then the following line is treated as special
based on this $S_i$.  If there is no ``$=>$ $T_i$'' part then
presumably $L_i$ is I, C, Z, or W, and the following line is
modifiable to suit these types.  If the ``$=>$ $T_i$'' part is
present, then the following line is to be converted as if the output
type were $T_i$.  If none of the $L_i$ match the $L_{out}$ from the
``MAKE...'' line, the following line is treated just like any other
line.

The following from DRDIVA illustrates specifying metavariables with a
higher than usual precision when $L_{out}$ is ``P'' or ``X''.  In all
other cases the declaration here would be what one would expect
from the letter specifying the precision.

\begin{verbatim}
c--D Next line special: P=>D, X=>Q
      double precision TSPECS(4), Y(IYDIM)...
\end{verbatim}

?VECPR is one of the few codes in MATH77 which allows all the real
precisions, and also allows integer.  The first pair of lines below
get converted to the second pair when DVECPR is converted to IVECPR.

\begin{verbatim}
c--D Next line special: I
      double precision  V(N)

c--I Next line special: I
      integer           V(N)
\end{verbatim}

Lines of type (5) and (6) mark the beginning and end, respectively,
of a set of lines in which all code modifications due to ``C$--$''
commands will be inhibited.

The ``C\%\%'' lines are documented here so that those looking at the
library source will understand their purpose.  These lines only have a
special meaning when they are not being treated in a special way for some
other reason.  In particular, if a ``C++ END'' statement would be
acceptable, then such lines are not treated in a special way.  When .C.\ =
.T., the ``C'' is deleted from column one in any sequence of consecutive
lines containing ``C\%\%'', and a C is inserted at the start of the
first line (one line only) that does not start in this way.  If .C.\ =
.F., and the lines are not being treated in a special way for some other
reason, then consecutive lines starting with ``\%\%'' have a C inserted
in column 1, and the next line has the character in column 1 deleted.
These lines provide a way of indicating changes required to get the code
converted to C, without using the ``C++'' mechanism, which makes the code
difficult to read when used frequently.

\subsection{Examples and Remarks}

If one wanted to get the partial double precision version of the
integration program DIVA, Chapter~14.1, one could set {\tt m77job} to
the following for a unix machine.  (For a PC replace the {\tt .f}
with {\tt.for}.)

{\tt \begin{tabbing}
  MAKE p\\
  FILE ?iva.f\\
  FILE ?ivag.f \\
  FILE ?ivadb.f
\end{tabbing}}

To convert {\tt amach} for a VAX running UNIX, {\tt m77job} would
contain the following to obtain the output file {\tt amach.f} from
the input file {\tt amach}.

{\tt \begin{tabbing}
  SET SYS = VAX\\
  FILE amach.f
\end{tabbing}}

\subsection{Functional Description}

The program {\tt m77con} converts between different versions of Fortran~77
source code that satisfy conventions used for MATH77.  It combines
functionality from earlier programs: ``The Specializer''
\cite{Krogh:1974:ALS}, ``MARVEL'' \cite{Lawson:1980:MAR}, and ``CHGTYP''
\cite{Lawson:1988:CHG}.

The code is processed a line at a time, first doing actions on
``C++...'' lines, then for other lines doing the actions called for
by ``C++...'' lines (except for replacing strings), then doing
actions on ``C$-$$-$...'' lines, and then doing other replacements.
Processing restarts with the first line after initial processing of
``C$-$$-$'' lines of types 1--3.

Except for strings defined by ``C++ Replace...'' lines, all
comparisons done by this code are case insensitive, all replacements
are done in the same case as for the text found, and blanks are
removed before comparisons are made in the source code.

Let ``in'' denote a string, keyword, variable name, or function name
we are searching for, and ``out'' denote the corresponding
replacement.  When conversion results in substitutions, if ``out'' is
longer than ``in'', characters to the right of ``in'' are shifted
right to leave enough space to insert ``out''.  A diagnostic
results if in the process nonblank characters are shifted beyond
column 72 (and thus lost).  If ``out'' is shorter than ``in'', then
``out'' is padded with blanks so as to occupy the same space as
``in''.

When type conversion is on (as it is if there is a ``MAKE...'' line
in the control file), then all lines, except those with ``++'' or
``$--$'' in columns 2 and 3, are examined in turn for the following:

If the ``in'' {\em keyword} is found, it is replaced by the ``out''
{\em keyword}.

Then ``in'' default function names for type conversion and getting
machine constants (see ``$T$ Defined by:...'' lines in Usage above)
are searched for, and when found are replaced by the corresponding
names of the ``out'' functions.  When searching for names (here and
below) they are only found if they are preceded and followed by a
nonletter or nondigit. Function names which do not have ``mach'' as
their last four letters are found only if followed by a `('.

Then the $V_i$'s and $v_i$'s generated from the ``C$--$L...'',
``C$--$T...'', and ``C$--$\&'' lines are searched for.  When found,
$L_{out}$ (or $T_{out}$ for names defined on ``C$--$T (Type)...''
lines or ``C$--$\&'' lines following such lines) replaces the letter
in the position of the ``?'', preserving the case of the letter that
was there.

Then, those strings defined by the ``C++ Replace...'' lines are
searched for and replaced if found.

Then, floating point constants are converted.  These are assumed to
consist of (not a letter).(0 or more digits)(the letter used for
floating point constants in the current version)(an optional + or
$-$)(a digit).  If such a string is found, the letter is replaced as
specified.

Whether type conversion is on or not, lines consisting of only ``END'' are
searched for.  When found, {\tt m77con} checks if there are any ``C++...''
actions still active or if the processing is not in ``usual precision''
mode.  In either of these cases a diagnostic is given and the processing
returns to normal mode.

\bibliography{math77}
\bibliographystyle{math77}

\subsection{Error Procedures and Restrictions}
    The program prints a variety of error messages on the standard
output. An error in the control file causes the program to stop.  In
most cases of errors in the special comments of the files being
processed, processing continues.  After 10 comparison errors in
a single file, no more comparison errors are printed for that file.

\subsection{Supporting Information}

The source language is ANSI Fortran~77.

Design and code due to F. T. Krogh, JPL, October~1994.  Multiple minor
modifications through April~1996.

\end{multicols}
\end{document}


% rubber: module xelatex
\documentclass[english,final,compress]{beamer}
%\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{fixltx2e}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{float}
\usepackage{wrapfig}
\usepackage{soul}
\usepackage{textcomp}
\usepackage{marvosym}
\usepackage{wasysym}
\usepackage{latexsym}
\usepackage{amssymb}
\usepackage{hyperref}
\tolerance=1000
\mode<beamer>{\usetheme{Bonn}}
\usepackage{fontspec}
\defaultfontfeatures{Mapping=tex-text}
\usepackage{xunicode}
\usepackage{xltxtra}
\setmainfont[Scale=0.86,Mapping=tex-text]{News Gothic MT}
\setsansfont[Scale=0.86,Mapping=tex-text]{News Gothic MT}
\setmonofont[Scale=0.86,Mapping=tex-text]{Andale Mono}
\usepackage{polyglossia}
\setdefaultlanguage{english}
\usepackage[EU1]{fontenc}
\usepackage{listings}
\usepackage{color}
\usepackage{csquotes}
\usepackage{mdwtab}
\usepackage{booktabs}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{amstext}
\usepackage{amsthm}
\usepackage{listings}
\renewcommand\maketitle{\frame[plain]{\titlepage}\addtocounter{framenumber}{-1}}
\providecommand{\alert}[1]{\textbf{#1}}

\setbeamercolor{insult}{fg=black,bg=red!30}
\setbeamercolor{noinsult}{fg=black,bg=green!30}
\setbeamerfont*{myserif}{family=\rmfamily,size=\scriptsize}

\title{Tutorial Machine Learning in Python}
\author{Andreas M\"{u}ller, Hannes Schulz, Nenad Bire\v sev and Sven
    Behnke\\[5mm]\includegraphics[width=.2\linewidth]{style/Logo_UBo_h24_4c-crop}}
\date{GK Bionik Tutorial 2012}
\begin{document}

\maketitle

\lstset{%
    basicstyle=\small\tt,
    keywordstyle=\color{beamer@bonnblue}\bfseries, % style for keywords
    numbers=none, % where to put the line-numbers
    numberstyle=\tiny, % the size of the fonts that are used for the line-numbers
    showspaces=false, % show spaces adding particular underscores
    showstringspaces=false, % underline spaces within strings
    showtabs=false, % show tabs within strings adding particular underscores
    tabsize=2, % sets default tabsize to 2 spaces
    captionpos=b, % sets the caption-position to bottom
    breaklines=true, % sets automatic line breaking
    breakatwhitespace=false,
}
\newcommand\fenc{f_{\mathrm{enc}}}
\newcommand\fdec{f_{\mathrm{dec}}}
\newcommand\Wand{\ensuremath{W_{\mathbf{and}}}}
\newcommand\Wor{\ensuremath{W_{\mathbf{or}}}}
\newcommand{\w}[1]{\ensuremath{\mathbf{#1}}}
\newcommand\loss{\ell}

\frame[plain]{\frametitle{Outline}\tableofcontents\addtocounter{framenumber}{-1}}
\section{Introduction to Python}

%\begin{frame}
%    \frametitle{Machine Learning Overview}
%    \begin{itemize}
%        \item Intro: Sven
%        \item Python: Hannes
%        \item Before Lunch: Unsupervised Learning (Hannes)
%        \item After Lunch: Supervised Learning (Nenad LinReg, Andy LogReg/kNN)
%    \end{itemize}
%\end{frame}

\begin{frame}
    \frametitle{A Short Introduction to Python}
    \begin{itemize}
        \item Please log in, using:
            \begin{description}
                \item[Username] \alert{gkbionik}
                \item[Password] \alert{tut0rial} (with a zero instead of the
                    ``o''!)
            \end{description}
    \end{itemize}
\end{frame}

\section{Unsupervised Learning}

\subsection{PCA}

\input{pca.tex}

\subsection{k-Means}

\input{kmeans.tex}

\section{Supervised Learning}

\begin{frame}
    \frametitle{Supervised Learning -- General}
    \begin{itemize}
	\item Task: Learn the function $ y = f(x) $ which predicts the output $y$ for the given input $x$, knowing the desired output
        \item Each example in data is a tuple of the input and desired output (target)
    \end{itemize}
\end{frame}

\begin{frame}
    \frametitle{Example: Supervised Learning}
    \begin{itemize}
       \item Input Data: 40 examples of persons (age, height, smoker).
	\item Targets: Weight of the person (desired output)
	\item Goal: Learn a function which predicts the weight for the new person
		knowing the age, height, nationality of person.

    \end{itemize}
\end{frame}

\begin{frame}
    \frametitle{Training / Test data}
    \begin{itemize}
	\item Learning is done on the training data, for which we know the input and targets
	\item To test if the model learned to predict the output, we use test data.
    \end{itemize}
\end{frame}

\subsection{Linear Regression}

\input{linreg.tex}

\subsection{Classification}
\begin{frame}
    \frametitle{Classification}
    \begin{itemize}
        \item Predict to which class a data point belongs.
        \item Training data are pairs $\left( (x_0, y_0), \cdots, (x_N, y_N)
                \right), x_i \in \mathbb{R}^n, y_i \in \{0, \cdots, k\}$
        \item Classical example: Spam / Ham.
        \item All classes known beforehand.
        \item Other examples: Digit recognition, cancer benign/malignant, \ldots
    \end{itemize}
\end{frame}

\subsection{Logistic Regression}

\input{logreg.tex}

\subsection{$k$ Nearest Neighbors}

\input{knn.tex}

\end{document}


\documentclass[11pt, oneside]{article}   	% use "amsart" instead of "article" for AMSLaTeX format

% \usepackage{draftwatermark}
% \SetWatermarkText{Draft}
 % \SetWatermarkScale{5}
% \SetWatermarkLightness {0.85}
% \SetWatermarkColor[rgb]{0.7,0,0}

\usepackage{geometry}                		% See geometry.pdf to learn the layout options. There are lots.
\geometry{letterpaper}                   		% ... or a4paper or a5paper or ...
%\geometry{landscape}                		% Activate for for rotated page geometry
%\usepackage[parfill]{parskip}    		% Activate to begin paragraphs with an empty line rather than an indent
\usepackage{graphicx}				% Use pdf, png, jpg, or eps� with pdflatex; use eps in DVI mode
								% TeX will automatically convert eps --> pdf in pdflatex
\usepackage{amssymb}
\usepackage{mathrsfs}
\usepackage{hyperref}
\usepackage{url}
\usepackage{authblk}
\usepackage{amsmath}
\usepackage{graphicx}
\usepackage{fixltx2e}
\usepackage{hyperref}
\usepackage{alltt}
\usepackage{color}
\usepackage{bigints}

\newcommand{\argmax}{\operatornamewithlimits{argmax}}
\newcommand{\argmin}{\operatornamewithlimits{argmin}}

\title{What is Rejection Sampling?}
\author{David Meyer \\ dmm@\{1-4-5.net,uoregon.edu,brocade.com,...\}}

% \date{September 30, 2015}							% Activate to display a given date or no date

\begin{document}
\maketitle

\section{Introduction}
\label{sec:intro}
Suppose that we want to sample from a distribution $f(x)$ that is difficult or impossible to sample from directly. Instead of trying to sample from $f(x)$, can we use a simpler distribution $q(x)$ from which sampling is easier? Perhaps, and the idea behind Rejection Sampling (aka Acceptance-rejection sampling) is to sample from $q(x)$ and apply some rejection/acceptance criterion such that the samples that are accepted are distributed according to $f(x)$.

\subsection{Envelope distribution and rejection criterion}

In order to be able to reject samples from $q(x)$ that aren't (approximately)   sampled from $ f(x)$, $q(x)$ must “cover” or envelop the distribution $f(x)$. This is generally done by choosing a constant $c > 1$ such that  $cq(x) > f(x)$, for all $x$. For this reason $cq(x)$ is often called the \emph{envelope distribution}. A common criterion for accepting samples from $x \sim q(x)$ is based on the ratio of the target distribution to that of the envelope distribution. The samples are accepted if

\begin{flalign}
\frac{f(x)}{cq(x)} > u
\end{flalign}

\noindent
where $u \sim Unif(0,1)$, and rejected otherwise. If the ratio is close to one, then $f(x) $ must have a large amount of probability mass around $x$ and that sample should  be more likely accepted. If the ratio is small, then it means that $f(x)$ has low probability mass around $x$ and we should be less likely to accept the sample. See Figure~\ref{fig:rgr}.  I think...

\begin{figure}
\center{\includegraphics[scale=0.75]{images/rejectionsamplingcriterion.png}}
\caption{Rejection Sampling with a Normal proposal distribution}
\label{fig:rgr}
\end{figure}

\end{document}