\section*{Web Appendix F}

Recall that a density $f(x;\theta)$ is identifiable if $f(x;\theta_{1})=f(x;\theta_{2})$
for all $x$ implies that $\theta_{1}=\theta_{2}.$ Call a density
$f(x;\theta)$ \textit{strongly identifiable} if $f(x;\theta_{1})/f(x;\theta_{2})$
being constant for all $x$ in an open interval $I$ implies that
$\theta_{1}=\theta_{2}$.
\paragraph{Proposition A.}\label{prop:identifiable}

Let $f(x;\theta)$ be a family of densities on $\mathbb{R}$, $-\infty=a_{1}<a_{2}<\ldots<a_{k+1}=\infty$
a sequence of cutoffs, and $f_{[a_{i},a_{i+1})}(x;\theta)$ the density
$f$ truncated to $[a_{i},a_{i+1})$. Let $\lambda_{i},k=1,\ldots k$
be positive numbers satisfying $\sum_{i=1}^{k}\lambda_{i}=1$. Then
the mixture
\[
g(x;\lambda,\theta)=\sum_{i=1}^{k}\lambda_{i}f_{[a_{i},a_{i+1})}(x;\theta)
\]
is identifiable in $(\lambda,\theta)$ if $f(x;\theta)$ is strongly
identifiable in $\theta$.

\paragraph{Proof.}
Assume that $g(x;\lambda_{1},\theta_{1})=g(x;\lambda_{2},\theta_{2})$.
Then $$\lambda_{1i}f_{[a_{i},a_{i+1})}(x;\theta_{1})=\lambda_{2i}f_{[a_{i},a_{i+1})}(x;\theta_{2})$$
for all $i$, thus
\[
\frac{\lambda_{1i}}{\lambda_{2i}}=\frac{f_{[a_{i},a_{i+1})}(x;\theta_{1})}{f_{[a_{i},a_{i+1})}(x;\theta_{2})}.
\]
This implies that $f(x;\theta_{1})/f(x;\theta_{2})$ is constant for
$x\in[a_{i},a_{i+1})$. But since $f(x;\theta)$ is strongly identifiable,
$\theta_{1}=\theta_{2}$, and, consequently, $\lambda_1 = \lambda_2$.

If $f(x;\theta)$ is real analytic and nowhere zero, $f(x;\theta_{1})/f(x;\theta_{2})$
is also real analytic and nowhere zero. By the Identity Theorem \citep[Corollary 1.2.6]{Krantz2002-bt}, if the ratio
$f(x;\theta_{1})/f(x;\theta_{2})$ is constant on some interval $I$,
then $f(x;\theta_{1})/f(x;\theta_{2})$ is constant everywhere, hence
$f(x;\theta_{1})=f(x;\theta_{2})$ everywhere. Thus a family of real
analytic nowhere zero densities is identifiable if and only if it is
strongly identifiable. Every exponential family of densities on the form
\[
f(x;\theta)=h(x)\exp(\eta(\theta)^{T}T(x)-A(\theta))
\]
satisfies this property, provided only that $h$ is nowhere zero real analytic
and $T$ is real analytic. In particular, the normal family satisfies
the properties.

Not every density is strongly identifiable. For instance, mixtures of uniforms are not strongly identifiable. And indeed, Proposition A fails when $f$ is a mixture of uniforms.


\section{Introduction}

Neurons, like all other cells, require proteins to function. Because of their morphological diversity and the fact that synapses can be hundreds of micrometers away from the some, neurons require an exquisite control of protein and mRNA distributions in both time and space.
Experimental evidence indicate the presence of mRNA in dendrites and recent reports highlight the importance of local translation in various forms of synaptic plasticities \supercite{Hafner2019, Younts2016}.

In their article, Fonkeu et al. (2019) develop a model framework to capture the spatial profiles of mRNA and protein in dendrites while taking into account: production, degradation, uni- and bi-directional transport \supercite{Fonkeu2019}. Validation of the model is obtained  by comparing with experimental data obtained from the analysis of CaMKII$\alpha$ mRNA, a major kinase involved in synaptic plasticity.

Here, we aimed at replicating model-based figures (therefore excluding Figures 2, 4, S1, S2, S3 that are either experimental or explanatory models). Code was not available on public repositories, except small pieces of scripts. Overall, the replication was successfull with only minor quantitative differences.

\section{Methods}

The model is based on the following equations:

\textbf{Equation 1} describes the mRNA dynamics using transcription rate ($\beta_{R}$), passive diffusion ($D_{R}$), transport velocity ($\nu_{R}$), degradation rate ($k_{R}$) and half-life ($T_{1/2}$).
\begin{equation}
  R^{den}_{ss}(x) = \frac{\beta_{R}\lambda_{R}}{k_{R}} e^{-\lambda_{R}x}x
\end{equation}
where $\lambda_{R} = \frac{\sqrt{\nu^{2}_{R} + 4D_{R}k_{R}}-\nu_{R}}{2D_{R}}$ and $k = \frac{\ln{2}}{T_{1/2}}$, $T_{1/2}$ being in seconds.

\textbf{Equation 2} describes protein dynamics using mRNA and protein transcription and translation rates ($\beta_{R}$ and $\beta_{P}$), diffusion coefficients ($D_{R}$ and $D_{P}$ respectively), transport velocities ($\nu_{R}$ and $\nu_{P}$) and degradation rates ($k_{R}$ and $k_{P}$).

\begin{equation}
  P^{den}_{SS}(x) = \frac{\beta_{P}\beta_{R}\lambda_{R}}{k_{R}(D_{P}\lambda^{2}_{R}+\nu_{P}\lambda_{R} - k_{P})}(-e^{-\lambda_{R}x} + \frac{D_{P}\lambda_{P}\lambda_{R} + \nu_{P}\lambda_{P}}{k_{P}}e^{-\lambda_{P}x})
\end{equation}

where $\lambda_{P} = \frac{\sqrt{\nu^{2}_{P} + 4D_{P}k_{P}}-\nu_{P}}{2D_{P}}$

In the case of proteins with 3'UTR localizing them to the soma, the \textbf{Equation 3} describes their distribution:
\begin{equation}
  P^{som}_{ss}(x) = \frac{\beta_{P}\beta_{R}\lambda_{P}}{k_{R}k_{P}} e^{-\lambda_{P}x}
\end{equation}

In neurons, both somatically and dendritically synthesized proteins contribute to the dendritic protein distribution. Thus, the total distribution of protein is a mixture of both \textbf{Equation 2} and \textbf{Equation 3} in the form of \textbf{Equation 4}:

\begin{equation}
  P^{tot}_{ss}(x) = S_{mRNA} \cdot z \cdot P^{som}_{ss}(x) + (1-S_{mRNA})  \cdot P^{den}_{ss}(x)
\end{equation}

where $S_{mRNA}$ denotes the fraction of mRNAs found in the soma and $z$ the fraction of somatically synthesized proteins that is transported to the dendrite.

\textbf{Table 1} provides values of rates used for simulations.

\begin{center}
  \begin{tabular}{|c|c|c|}
    \hline
    & mRNA & Protein \\
    \hline
    Transcription (mRNA/s) & $\beta_{R} = 0.001$ & \\
    \hline
    Translation (protein/s) & & $\beta_{P} = 0.021$ \\
    \hline
    Diffusion ($\mu m^{2}/s$) & $D_{R}=3.4e^{-3}$ & $D_{P}=0.24$ \\
    \hline
    Velocity ($\mu m/s$) & $\nu_{R}=6.7e^{-3}$ & $\nu_{P}=0$ \\
    \hline
    Half life & $T_{1/2}=16$ hours & $T_{1/2}=6.67$ days \\
    \hline
  \end{tabular}
\end{center}

\textbf{Table 2} provides values for other parameters. Values were rounded to 2 decimals. Of note, using these values can lead to slight changes in the quantitative results. Full values can be found in the code files.

\begin{center}
  \begin{tabular}{|c|c|}
    \hline
    Name & Value \\
    \hline
    $S_{mRNA}$ & 0.557 \\
    \hline
    $z$ & 0.22 \\
    \hline
  \end{tabular}
\end{center}

\section{Results}

In \textbf{Figure 1}, we show the range of possible dendritic mRNA and protein distributions according to the smallest and largest experimental values from the literature (Figure 1C,D in the orignal article). We observed small quantitative differences with values reported in the original article (31.1\% instead of 29\% reduction of protein cncentration in conditions of reduced protein mobility).

\begin{figure}[H]
  \includegraphics[width=\textwidth]{Figure1.pdf}
  \caption{Replication of the possible range of dendritic mRNA and protein distribution according to the literature.  Color code denotes the upper bound (dark blue and red) and lower bound (light blue and orange) for the respective distributions (\textbf{A}) mRNA distribution obtained for candidate values from the literature. Upper bound: $D_{R} = 0.0038\mu m^{2}/s$ and $\nu_{R}=1.3\mu m/s$. Lower bound:  $D_{R} = 0.003\mu m^{2}/s$ and $\nu_{R}=0.0058\mu m/s$. (\textbf{B}) Protein distribution obtained for candidate values from the literature.Upper bound: $D_{P} = 4.5\mu m^{2}/s$ and $\nu_{P}=0\mu m/s$. Lower bound:  $D_{P} = 0.023\mu m^{2}/s$ and $\nu_{R}=0\mu m/s$.}
\end{figure}

In \textbf{Figure 2}, we show the influence of single parameter variations on mRNA and protein distribution. The initial parameters used are the one experimentally confirmed in the study: $D_{R}=3.4\cdot10^{-3} \mu m^{2}/s, \nu_{R}=6.7 \cdot 10^{-3} \mu m/s$. Qualitative inspection of the obtained graphs showed similar behavior and allowed to reach similar conclusions.

\begin{figure}[H]
  \includegraphics[width=\textwidth]{Figure2.png}
  \caption{Consequences of modulating mRNA parameters on mRNA and protein distributions. (\textbf{A, B}) Impact of mRNA velocity. (\textbf{D, E}) Impact of mRNA diffusion.(\textbf{F, G}) Impact of mRNA lifetime. In all panels, distributions were normalizxed to the original value. Alternative normalization were also explored and were successfully replicated (LINK ??)}
\end{figure}


% This is part of the TFTB Reference Manual.
% Copyright (C) 1996 CNRS (France) and Rice University (US).
% See the file refguide.tex for copying conditions.

\markright{fmlin}
\section*{\hspace*{-1.6cm} fmlin}

\vspace*{-.4cm}
\hspace*{-1.6cm}\rule[0in]{16.5cm}{.02cm}
\vspace*{.2cm}

{\bf \large \sf Purpose}\\
\hspace*{1.5cm}
\begin{minipage}[t]{13.5cm}
Signal with linear frequency modulation.
\end{minipage}
\vspace*{.5cm}

{\bf \large \sf Synopsis}\\
\hspace*{1.5cm}
\begin{minipage}[t]{13.5cm}
\begin{verbatim}
[y,iflaw] = fmlin(N)
[y,iflaw] = fmlin(N,fnormi)
[y,iflaw] = fmlin(N,fnormi,fnormf)
[y,iflaw] = fmlin(N,fnormi,fnormf,t0)
\end{verbatim}
\end{minipage}
\vspace*{.5cm}

{\bf \large \sf Description}\\
\hspace*{1.5cm}
\begin{minipage}[t]{13.5cm}
        {\ty fmlin} generates a linear frequency modulation, going from
{\ty fnormi} to {\ty fnormf}.  The phase of this modulation is such that
{\ty y(t0)=1}.\\

\hspace*{-.5cm}\begin{tabular*}{14cm}{p{1.5cm} p{8.5cm} c}
Name & Description & Default value\\
\hline
        {\ty N }      & number of points\\
        {\ty fnormi}  & initial normalized frequency & {\ty 0.0}\\
        {\ty fnormf}  & final   normalized frequency & {\ty 0.5}\\
        {\ty t0}      & time reference for the phase & {\ty N/2}\\
  \hline {\ty y}       & signal\\
        {\ty iflaw }  & instantaneous frequency law  \\
\hline
\end{tabular*}

\end{minipage}
\vspace*{1cm}

{\bf \large \sf Example}
\begin{verbatim}
         z=amgauss(128,50,40).*fmlin(128,0.05,0.3,50);
         plot(real(z));
\end{verbatim}
\vspace*{.5cm}

{\bf \large \sf See Also}\\
\hspace*{1.5cm}
\begin{minipage}[t]{13.5cm}
\begin{verbatim}
fmconst, fmsin, fmodany, fmhyp, fmpar, fmpower.
\end{verbatim}
\end{minipage}


% \documentclass{article}
% \usepackage[utf8]{inputenc}
% \usepackage{amsmath}

% \title{Toda Lattice, Double Bracket}
% \author{Lusa Zhan}
% \date{September 2016}

% \begin{document}

% \maketitle

% \section{Equivalence between ODE and Lie bracket notation}

The central idea of analog sorting as described in~\cite{bloch, brockett} makes use of the Toda lattice. The system of Hamiltonian equations in (1) associated with the Hamiltonian in (2) gives us the following set of equations
\begin{align*}
\dot{p_k} &= \exp(q_{k-1}-q_{k})-\exp(q_{k}-q_{k+1}) \\
\dot{q_k} &= p_k
\end{align*}
where the boundary conditions are set so that $\exp(x_0-x_1)=\exp (x_n-x_{n+1})=0$.

This system is also analogous to the double bracket notation
\begin{align}
\dot{H} = [H,[H,N]]
\end{align}

where the brackets stand for the Lie bracket $[A,B] = AB-BA$. The connection between the Hamiltonian system  and the double bracket notation of the Toda lattice will be discussed and outlined in the following sections.

\subsubsection{Toda lattice - ODE form}

The above system of ordinary differential equations can be transformed into the system described in~\cite{harvard_robo} using a change of variables.
\begin{align}
x_k &= -\frac{1}{2}p_k \nonumber \\
y_k &= \frac{1}{2}\exp(\frac{q_k-q_{k+1}}{2})
\end{align}

In that case,
\begin{align*}
    \dot{x_k} &= -\frac{1}{2}\dot{p_k} \\
              &= -\frac{1}{2}(exp(q_{k-1}-q_{k})-exp(q_{k}-q_{k+1})) \\
              &= -\frac{1}{2}(4y^2_{k-1}-4y^2_k) \\
              &= 2y^2_k-2y^2_{k-1}
\end{align*}

and
\begin{align*}
    \dot{y_k} &= \frac{1}{2}\exp(\frac{q_k-q_{k+1}}{2})\frac{\dot q_k-\dot q_{k+1}}{2} \\
              &= y_k\frac{p_k-p_{k+1}}{2} \\
              &= y_k(x_{k+1}-x_k)
\end{align*}

Taking into account the boundary conditions $y_0=y_n=0$, we get the desired system of ODEs with
\begin{align}
    \dot{x_k} &= 2y^2_k-2y^2_{k-1} \nonumber \\
    \dot{y_k} &= y_k(x_{k+1}-x_k) \\
    y_0 &= y_n = 0 \nonumber
\end{align}

This is the system of ODEs we will solve in the analog chip and in our simulations.

\subsubsection{Toda lattice - Jacobi matrix}

The connection between the Toda lattice and the double bracket notation $\dot{H} = [H,[H,N]]$ can be made through the Jacobi Matrix form of the Toda lattice. The Jacobi matrix for the Hamiltonian system after the change of variables (4) is given by
\begin{align}
 H = \begin{bmatrix}
    x_{1} & y_{1} & 0  & \dots & 0 \\
    y_{1} & x_{2} & y_{2} & \dots & 0 \\
     & & \ddots & \\
          &       & y_{n-2} & x_{n-1} & y_{n-1}\\
    0 & \hdots & & y_{n-1} & x_{n}
\end{bmatrix}
\end{align}
This is the form of $H$ required for analog sorting as outlined by Brockett in ~\cite{brockett}.

In order to get the double bracket form, we need a diagonal matrix $N = \text{diag}(n, n-1, \dots, 1)$ whose role will be discussed in 2.5.1.

\begin{align*}
N = \begin{bmatrix}
        n & 0 & \hdots & 0 \\
        0 & n-1 & \\
        \vdots &  & \ddots & \vdots \\
        0 & \hdots & & 1
    \end{bmatrix}
\end{align*}

From this, we can calculate $[H[H,N]] = H[H,N]-[H,N]H$ step by step:

\[
HN = \begin{bmatrix}
        nx_1 & (n-1)y_1 & \hdots & 0 \\
        ny_1 & (n-1)x_2 & \hdots & 0 \\
        \vdots & & \ddots & 0\\
         &  & 2x_{n-1} & y_{n-1} \\
        0 & \hdots & 2y_{n-1} & x_n

    \end{bmatrix}
\]

\[
NH = \begin{bmatrix}
        nx_1 & ny_1 & \hdots & 0 \\
        (n-1)y_1 & (n-1)x_2 & \hdots & 0 \\
        \vdots & & \ddots & 0\\
         &  & 2x_{n-1} & 2y_{n-1} \\
        0 & \hdots & y_{n-1} & x_n

    \end{bmatrix}
\]

\[
HN-NH = \begin{bmatrix}
        0 & -y1 & \hdots &  & 0 \\
        y_1 & 0 & -y_2 & \hdots & 0 \\
        \vdots & \ddots & \ddots & \ddots & 0\\
         & & y_{n-2}& 0 & -y_{n-1} \\
        0 & & \hdots & y_{n-1} & 0

    \end{bmatrix}
\]

\[
H[H,N] = \begin{bmatrix}
        y_1^2 & -x_1y_1 & \hdots & 0 \\
        x_2y_1 & -y_1^2+y^2_2 &\hdots & 0 \\
        y_1y_2 & \ddots & & 0\\
        \vdots & & y^2_{n-1}-y^2_{n-2} & -x_{n-1}y_{n-1} \\
        0 & \hdots & x_ny_{n-1} & -y^2_{n-1}

    \end{bmatrix}
\]

\[
[H,N]H = \begin{bmatrix}
        y_1^2 & -x_2y_1 & \hdots & 0 \\
        x_1y_1 & y_1^2-y^2_2 &\hdots & 0 \\
        y_1y_2 & \ddots & & 0\\
        \vdots &  & -y^2_{n-1}+y^2_{n-2} & -x_{n}y_{n-1} \\
        0 & \hdots & x_{n-1}y_{n-1} & y^2_{n-1}

    \end{bmatrix}
\]
\\

Therefore, we get \\

\[[H,[H,N]] =
\begin{bmatrix}
    2y_1^2 & y_1(x_2-x_1) & 0 \\
    y_1(x_2-x_1) & -2(y_1^2-y^2_2) & 0\\
    0 & \ddots & 0\\
    \vdots & & y_{n-1}(x_{n}-x_{n-1}) \\
    0 & \hdots & -2y^2_{n-1}
\end{bmatrix}
\]

This is equivalent to the result we get from combining the matrix form of $H$ with the values for $\dot{x}$ and $\dot{y}$
\[\dot{H} = \begin{bmatrix}
    \dot{x}_{1} & \dot{y}_{1} & 0  & \dots & 0 \\
    \dot{y}_{1} & \dot{x}_{2} & \dot{y}_{2} & \dots & 0 \\
     & & \ddots & \\
     & & \dot{y}_{n-2} & \dot{x}_{n-1} & \dot{y}_{n-1}\\
    0 & \hdots & & \dot{y}_{n-1} & \dot{x}_{n}

\end{bmatrix}\]

In total, we conclude that the double bracket notation of the Toda lattice used in other papers is analogous to the system of ODEs. We use the equivalent system of ODEs to construct the analog sorter.


\documentclass[11pt]{article}

\usepackage{array}
\usepackage{clrscode3e}
\usepackage{amsmath}
\usepackage{kbordermatrix}

\setlength{\parindent}{0em}
\setlength{\parskip}{1em}

\begin{document}

\title{Efficient Calculation of Interaction Features on Sparse Matrices}
\author{Andrew Nystrom}
\date{}

\maketitle

\begin{abstract}%   <- trailing '%' for backward compatibility of .sty file
FILL THIS IN
\end{abstract}

\section{Introduction}

Introduction
Interaction features are a way of capturing correlations between features in a machine
learning setting. A feature vector $\vec{x}$ of dimensionality $D$ has second degree interaction features
$\{x_i \cdot x_j : i, j \in \{0,1,..., D-1\} \land i < j\}$,
so a $D$ dimensional vector has $\binom{D}{2} = \frac{D^2-D}{2}$ second degree interaction features. A naive
approach to calculating these features is to simply iterate through the combinations of the column indices.
For a sparse vector, many of the resulting interaction features would be zero, and could therefore be ignored.
This work describes a method to efficiently calculate second degree interaction features for a sparse matrix
that has time and space complexities that decrease quadratically with the density of the input matrix with respect to the naive approach.

$\{x_i \cdot x_j : i, j \in \{0,1,..., D-1\} \land i \le j\}$  \\
\\
$\{(i,j) : i, j \in \{0,1,..., D-1\} \land i \le j\} \to \{0, 1, ..., \frac{D^2+D}{2}-1\}$ \\

$i$
$j$

$\vec{x}$

\begin{codebox}
\Procname{$\proc{Dense Polynomials}(A)$}
    \zi $N \gets$ row count of $A$
    \zi $D \gets$ column count of $A$
    \zi $B$ $\gets$ Matrix of size $N \times \frac{D^2+D}{2}$
    \zi \For $\id{row}$ in $A$ \Do
    \zi     $k \gets 0$
    \zi     \For $\i \gets 0 \To D$ \Do
    \zi         \For $\j \gets i \To D$ \Do
    \zi             $B[i, k] \gets \id{row}[i] \cdot \id{row}[j]$
    \zi             $k \gets k + 1$
                \End
            \End
       	\End
\end{codebox}

$[a, b, c, d, e]$

$[ab, ac, ad, ae, bc, bd, be, cd, ce, de]$

\renewcommand{\kbldelim}{(}% Left delimiter
\renewcommand{\kbrdelim}{)}% Right delimiter
\[
  \kbordermatrix{
        & x_0 & x_1 & x_2 & x_3 & x_4 \\
    x_0 & 0 & 1 & 2 & 3 & 4\\
    x_1 & - & 5 & 6 & 7 & 8\\
    x_2 & - & - & 9 & 10 & 11\\
    x_3 & - & - & - & 12 & 13\\
    x_4 & - & - & - & - & 14\\
  }
\]

$\text{polynomial-index}(i, j | D) = \frac{2Di-i^2+2j-3i-2}{2}+i+1$

%Consider the following matrix:

%\[ \left( \begin{array}{cccc}
%3 & 0 & 0 & 3 \\
%0 & 4 & 2 & 0 \\
%1 & 2 & 0 & 3 \end{array} \right)\]
\[ \left( \begin{array}{ccccc}
A & b & c & d \end{array} \right)\]

%\[ \left( \begin{array}{cccccccccc}
%1 & 2 & 0 & 3 & 0 \end{array} \right)\]

%If each row is an instance vector, then the interaction feature matrix is

%\[ \left( \begin{array}{cccccc}
%0 & 0 & 9 & 0 & 0 & 0 \\
%0 & 0 & 0 & 8 & 0 & 0 \\
%2 & 0 & 3 & 0 & 6 & 0 \end{array} \right)\]

%Note that there are $\binom{D}{2} = \frac{D^2-D}{2}$ columns in the interaction matrix, which is D choose 2,
%since we generate products of all combinations of 2 features in the original matrix.
%Which column corresponds with which product pair is not important so long as it’s
%consistent. In this example, each column in the interaction matrix corresponded to the
%following product pairs: $(1, 2),  (1, 3),  (1, 4),  (2, 3), ( 2, 4), (3, 4)$.

%Notice that the interaction matrix contains many zero entries. This is of course because
%the original matrix contained zero entries, so the interaction features, which are
%products of pairs of features, contain many zeros. This means that the only products that
%need to actually be calculated or those for which both features in the combination are
%nonzero. If the original matrix is sparse and represented in a sparse matrix format
%(e.g. compressed sparse row), a list of nonzero column indices are stored for each row
%and are easily retrievable in $O(1)$ time. Interaction features can be generated from this
%list via the following method.

\section{Approach}
Let the list of nonzero columns for a given row $\vec{x}$ be denoted by $N_{zc}$. The nonzero second degree
interaction features are simply the products of all combinations of two elements whose
columns are in $N_{zc}$. However, to properly place an interaction feature into the correct column, a mapping from the column
index pairs of $N_{zc}$ into the columns of the interaction matrix is needed. The mapping is
from the space (a, b) where a,b are in $1,2,..., D$ onto the space $1,2,..., \frac{D^2-D}{2}$. This
is isomorphic to mapping the coordinates of the upper triangle of a matrix onto a flat
list. The following is a proof by construction for such a mapping.

INSERT JOHN'S PROOF HERE

With this mapping, an algorithm for generating second degree interaction features on a
matrix $A$ can be formulated as follows:

\begin{codebox}
\Procname{$\proc{Sparse Polynomials}(A)$}
    \zi $\func{map}(a, b) = \frac{2Da-a^2+2b-3a-2}{2}+a+1$
    \zi $N \gets$ row count of $A$
    \zi $D \gets$ column count of $A$
    \zi $B$ $\gets$ Compressed Sparse Row Matrix of size $N \times \frac{D^2+D}{2}$
    \zi \For $\id{row}$ in $A$ \Do
    \zi     $N_{zc} \gets$ nonzero columns of $row$
    \zi     \For $i \gets 0 \To |N_{zc}|$ \Do
    \zi         \For $j \gets i \To |N_{zc}|$ \Do
    \zi             $k \gets \func{map}(i, j)$
    \zi             $r \gets$ index of $\id{row}$
    \zi             $B[r, k] \gets \id{row}[i] \cdot \id{row}[j]$
                \End
            \End
       	\End
\end{codebox}

\section{Complexity Analysis}
Assume that A is a matrix with sparsity $0 < d < 1$, $N$ rows, and $D$ columns. Finding
interaction features with the proposed algorithm has time and space complexity
$\func{O}(d N D^2)$,
whereas a naive approach of using non-sparse matrices and multiplying all column
combinations has time and space complexity $\func{O}(N D^2)$. The algorithm is therefore an
improvement by a factor of the density factor of $A$.

This can represent a large gain in speed and time. For example, the 20 Newsgroups dataset
has density $d$ of 0.12 when its unigrams are represented in a vector space model. This
means the proposed approach would take less than $\frac{1}{8}$ time and memory.

The real benefit of this method is revealed when the average complexity is analysed. The
number of interactions calculated for a given row are $\binom{|N_{zc}|}{2}$. If the matrix has
density $d$, then on average, $N_{zc} = D d$, so the number of interaction features
calculated in total is

\begin{align*}
N \binom{d D}{2} &= N \frac{(Dd)!}{2!(Dd-2)!}\\
    \\
    &= N \frac{(D^2d^2-Dd)}{2}
\end{align*}

This means that the average complexity decreases quadratically with the density.

\section{Future Work}
The approach for generating second degree interaction features required a mapping from
combinations of two to the space $1,2,...,\frac{D^2-D}{2}$, which is isomorphic to a mapping from
the indices of an upper triangular matrix to the indices of a flat list of the same size.
To generate third degree interaction features, a mapping from combinations of three
$(a,b,c)$ to the space $1,2,...\frac{D^3-3D^2+2D}{6}$ (which is $\binom{D}{3}$), or the upper $3$-simplex of a tensor to a flat
list of the same size $\frac{D^3-3D^2+2D}{6}$ would be required. In general, for interaction
features of degree k, the upper $k$-simplex of a $k$-dimensional tensor must be mapped to the
space $1,2,...\frac{D!}{k!(D-k)!}$. A similar approach for finding these mappings could be taken
as the one used here for $k=2$.

Motivation for deriving mapping functions for higher orders
of interaction features is that the average complexity of generating degree $k$ interaction
features is $N \binom{Dd}{k}$, which decreases polynomially with respect to k compared to
generating the features naively.

\vskip 0.2in
\bibliography{sample}

\end{document}


The is the first paragraph of the Softcover article template. It shows how to write a document in \PolyTeX, a subset of the \LaTeX\ typesetting language optimized for writing ebooks.\footnote{Pronunciations of ``LaTeX'' differ, but \emph{lay}-tech is the one I prefer.}

This is the second paragraph, showing how to \emph{emphasize} text. You can also make text \textbf{bold}.

\section{A section}
\label{sec:a_section}

This is a section. We'll take a look at some of the features supported by Softcover.

\subsection{Source code}

In plain Markdown, you can typeset code samples and other verbatim text using four spaces of indentation:

\begin{verbatim}
def hello
  puts "hello, world"
end
\end{verbatim}

Softcover also supports GitHub-style ``code fencing'' with language-specific syntax highlighting:

%= lang:ruby
\begin{code}
# "Hello, world!" in Ruby.
def hello
  puts "hello, world!"
end
\end{code}

The second of these can be combined with Softcover's \kode{codelisting} environment to make code listings via embedded \LaTeX, as shown in Listing~\ref{code:hello}.

\begin{codelisting}
\codecaption{Hello, world.}
\label{code:hello}
%= lang:ruby
\begin{code}
# "Hello, world!" in Ruby.
def hello
  puts "hello, world!"
end
\end{code}
\end{codelisting}

\subsection{Mathematics}

Softcover supports mathematical typesetting via embedded \LaTeX. This includes both inline math, such as \( \phi^2 - \phi - 1 = 0, \) and centered math, such as
\[ \phi^2 - \phi - 1 = 0. \]
Softcover also supports numbered equations via embedded \LaTeX, as seen in Eq.~\eqref{eq:phi} and Eq.~\eqref{eq:gauss}.

\begin{equation}
\label{eq:phi}
\phi = \frac{1+\sqrt{5}}{2} \approx 1.618
\end{equation}

\begin{equation}
\label{eq:gauss}
\mathbf{\nabla}\cdot\mathbf{B} = 0 \qquad\mbox{Gauss's law}
\end{equation}

\section{Images and tables}
\label{sec:images_and_tables}

This is the second section. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse
cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non
proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

\subsection{Images}

Softcover supports the inclusion of images, like this:

\image{images/figures/01_michael_hartl_headshot.jpg}

Using \LaTeX\ labels, you can also include a caption (as in Figure~\ref{fig:captioned_image}) or just a figure number (as in Figure~\ref{fig:figure_number}).

\begin{figure}[h]
\begin{center}
\image{images/figures/01_michael_hartl_headshot.jpg}
\end{center}
\caption{Some dude.\label{fig:captioned_image}}
\end{figure}

\begin{figure}[h]
\begin{center}
\image{images/figures/01_michael_hartl_headshot.jpg}
\end{center}
\caption{\label{fig:figure_number}}
\end{figure}

\subsection{Tables}

Softcover supports raw tables via the \LaTeX\ \kode{table} or \kode{longtable} environments.

\begin{longtable}{|l|l|l|l|}
\hline
\textbf{HTTP request} & \textbf{URL} & \textbf{Action} & \textbf{Purpose}\\
\kode{GET} & /users & \kode{index} & page to list all users\\
\kode{GET} & /users/1 & \kode{show} & page to show user with id \kode{1}\\
\kode{GET} & /users/new & \kode{new} & page to make a new user\\
\kode{POST} & /users & \kode{create} & create a new user\\
\kode{GET} & /users/1/edit & \kode{edit} & page to edit user with id \kode{1}\\
\kode{PATCH} & /users/1 & \kode{update} & update user with id \kode{1}\\
\kode{DELETE} & /users/1 & \kode{destroy} & delete user with id \kode{1}\\
\hline
\end{longtable}

Softcover also supports \kode{tabular} environments, as shown in Table~\ref{table:figure_placement}.

\begin{table}
\caption{Options for a float placement specifier.\label{table:figure_placement}}
\begin{tabular}{l|l}
\textbf{Specifier} & \textbf{Placement} \\ \hline
\kode{h} & Place the float \emph{approximately} here \\
\kode{h!} & Place the float \emph{(almost) exactly} here \\
\kode{t} & Place at the top of the page \\
\kode{b} & Place at the bottom of the page \\
\kode{p} & Put on a special page for floats only
\end{tabular}
\end{table}

\section{Final section}

This is the final section. The previous sections were Section~\ref{sec:a_section} and Section~\ref{sec:images_and_tables}.


\section{The predicate \Unchanged}
\Label{sec:unchanged}

Many of the algorithms in this section iterate sequentially over one or several sequences.
For the verification of such algorithms it is often important to express that a section
of an array, or the complete array, have remained \emph{unchanged}.
As this cannot always be expressed by an \inl{assigns} clause,
we introduce in the following listing the overloaded predicate
\logicref{Unchanged}.
The expression \inl{Unchanged\{K,L\}(a,m,n)} is true if the range
\inl{a[m..n-1]} in state~\inl{K} is element-wise equal to that range in state~\inl{L}.

\input{Listings/Unchanged.acsl.tex}

In some situations we use the predicate \ArrayUpdate,
which relies on the predicate \Unchanged and the the logic function \logicref{At},
to concisely describe which parts of an array have changed or remained unchanged
when updating an individual array element.

\input{Listings/ArrayUpdate.acsl.tex}

\clearpage

In the following listing we show a few lemmas for \logicref{Unchanged}
that we need for the verification of various algorithms.

\input{Listings/UnchangedLemmas.acsl.tex}

\begin{itemize}
\item
Lemma~\logicref{UnchangedShrink} states that if the range~\inl{a[m..n-1]} does
not change when going from state~\inl{K} to state~\inl{L}, then~\inl{a[p..q-1]}
does not change either, provided the latter is a subrange of the
former, i.e.\ provided $0 \leq m \leq p \leq q \leq n$ holds.

\item
Lemma~\logicref{UnchangedExtend} expresses the simple fact that ``unchangedness'' is an inductive property.

\item
Lemma~\logicref{UnchangedShift} states how \Unchanged behaves under pointer additions.

\item
Lemmas~\logicref{UnchangedSymmetric} and~\logicref{UnchangedTransitive} express respectively
the symmetry and transitivity of \Unchanged with respect to program states.

\end{itemize}

\clearpage


\chapter{Frequentist statistics}

Attempts have been made to devise approaches to statistical inference that avoid treating parameters like random variables, and which thus avoid the use of priors and Bayes rule. Such approaches are known as \textbf{frequentist statistics}, \textbf{classical statistics} or \textbf{orthodox statistics}. Instead of being based on the posterior distribution, they are based on the concept of a sampling distribution.

\section{Sampling distribution of an estimator}
In frequentist statistics, a parameter estimate $\hat{\vec{\theta}}$ is computed by applying an \textbf{estimator} $\delta$ to some data $\mathcal{D}$, so $\hat{\vec{\theta}}=\delta(\mathcal{D})$. The parameter is viewed as fixed and the data as random, which is the exact opposite of the Bayesian approach. The uncertainty in the parameter estimate can be measured by computing the \textbf{sampling distribution} of the estimator. To understand this

\subsection{Bootstrap}
We might think of the bootstrap distribution as a “poor man’s” Bayes posterior, see (Hastie et al. 2001, p235) for details.

\subsection{Large sample theory for the MLE *}

\section{Frequentist decision theory}
In frequentist or classical decision theory, there is a loss function and a likelihood, but there is no prior and hence no posterior or posterior expected loss. Thus there is no automatic way of deriving an optimal estimator, unlike the Bayesian case. Instead, in the frequentist approach, we are free to choose any estimator or decision procedure $f: \mathcal{X} \rightarrow \mathcal{Y}$ we want.

Having chosen an estimator, we define its expected loss or \textbf{risk} as follows:
\begin{equation}\begin{split}
R_{\mathrm{exp}}(\theta,f) & \triangleq \mathbb{E}_{p(\tilde{\mathcal{D}}|\theta^*)}[L(\theta^*, f(\tilde{\mathcal{D}}))] \\
    & =\int L(\theta^*, f(\tilde{\mathcal{D}}))p(\tilde{\mathcal{D}}|\theta^*)\mathrm{d}\tilde{\mathcal{D}}
\end{split}\end{equation}
where˜$\tilde{\mathcal{D}}$ is data sampled from “nature’s distribution”, which is represented by parameter $\theta^*$. In other words, the expectation is wrt the sampling distribution of the estimator. Compare this to the Bayesian posterior expected loss:
\begin{equation}
\rho(f|\mathcal{D},)
\end{equation}

\section{Desirable properties of estimators}

\section{Empirical risk minimization}

\subsection{Regularized risk minimization}

\subsection{Structural risk minimization}

\subsection{Estimating the risk using cross validation}

\subsection{Upper bounding the risk using statistical learning theory *}

\subsection{Surrogate loss functions}
\label{sec:Surrogate-loss-functions}

\textbf{log-loss}
\begin{equation}\label{eqn:log-loss}
L_{\mathrm{nll}}(y,\eta)=-\log p(y|\vec{x},\vec{w})=\log(1+e^{-y\eta})
\end{equation}

\section{Pathologies of frequentist statistics *}


\documentclass[12pt]{article}

\usepackage{amsmath}
\usepackage{graphicx}
\usepackage{hyperref}
\usepackage[latin1]{inputenc}
\usepackage{geometry}
\usepackage{graphicx}
\usepackage{titlesec}
\usepackage{pagecolor}

\date{}

\begin{document}
\pagecolor{white}

\section{Question 1}

$$n + d = 2011 <=> d = 2011 - n$$
$$\frac{n} {d} < \frac{1}{3}$$
$$\frac{n}{2011 - n} <  \frac{1}{3}$$
$$3n < 2011 - n$$
$$4n < 2011$$
$$n < 502.75$$
Due to the constraint that $n$ and $d$ are positive integers, the maximum value for $n$ is $502$. Therefore $d = 2011 - n = 2011 - 502 = 1509$.

\section{Question 2}

Let X be the random variable modeling the outcome of the bet, where $x_1$ is the amount by which one's money, $m$, is increased in the event that the bet is favorable, and $x_2$ is the amount by which $m$ is increased if the bet is not favorable. We know that $x_1$ and $x_2$ are complements. Therefore, the expectation of such a variable $X$ is:

$$E[X; m] = \sum_i x_iP(x_i) = 3mP(x_1) - mP(x_2) = 3mP(x_1) - m(1 - P(x_1)) = 4mP(x_1) - m$$
$$= m(4P(x_1) - 1)$$
In order for the bet to be favorable, we would need the expectation of $X$ to be positive, i.e.,:

$$E[X; m] = m(4P(x_1) - 1) > 0$$
$$P(x_1) > 0.25$$
Let $n$ be the number of face cards in the first 5 cards, and let $c$ be the event where the sixth card is a face card, i.e., one's money is increased. Then:

$$P(c | n = i) = \frac{12 - i}{47} $$
Therefore:
$$P(c | n = 0) = 0.255$$
$$P(c | n = 1) =  0.234$$
Thus we can see that the only way the bet is favorable (i.e., $P(x_1) = P(c | n = i) > 0.25$) is when $i = 0$. We now need to figure out the probability of such an occurrence:

$$P(n = 0) = \frac{{12 \choose 0}{40 \choose 5}}{{52 \choose 5}} = 0.25318$$

\section{Question 3}

We have the following parameters for the Poisson distribution:

$$\lambda = 100 / 5 = 20$$
$$\alpha = 0.05$$
$$n = 60$$
$$k = n\lambda = (60)(20) = 1200$$

$$CI = [\frac{1}{2}\chi^2(\frac{\alpha}{2}; 2k), \frac{1}{2}\chi^2(1 - \frac{\alpha}{2}; 2k + 2)]
= [\frac{1}{2}\chi^2(0.025; 2400), \frac{1}{2}\chi^2(0.975; 2402)]
= [1133.1, 1269.9]$$

\section{Question 4}

This is a one-sided Z-test.

$$Z^* = \frac{\hat{p} - p_0}{\sqrt{\frac{p_0(1-p_0)}{n}}}  = \frac{(\frac{26}{200} - 0.1)}{\sqrt{\frac{0.1(0.9)}{200}}} = 1.414$$
$$p = P(Z \geq Z^*) = 0.0787 > 0.05$$
Therefore we fail to reject the null hypothesis.

\end{document}


\documentclass{article}

\begin{document}

\def\subI{${}_I$}
\def\subF{${}_F$}
\def\subD{${}_D$}
\def\ifso{\mathbin{?}}

\section{Rounding}

Converting a rational number $x \in {\cal Q}$ to a nearby
integer $n \in {\cal Z}$ can be done in surprisingly many
ways.  We shall take the floor operation
\[ \lfloor x \rfloor = \max \{n \in {\cal Z} | n \le x\} \]
as the basic operation.  We also need $\bot$ (undefined),
even$(n)$ testing whether $n$ is a multiple of 2,
$p \ifso t : f$ (if $p$ then $t$ else $f$), and $\sigma(x)$ =
$x\ge 0 \ifso 1 : -1$.

\begin{tabular}{lll}
exact & $x=\lfloor x\rfloor \ifso \lfloor x \rfloor : \bot$ &
        exception if not integral\\
down  & $\lfloor x \rfloor$             & floor\\
up    & $\lceil x \rceil = -\lfloor -x \rfloor$ & ceiling\\
in    & $\sigma(x)\times\lfloor|x|\rfloor$ & truncate\\
out   & $\sigma(x)\times\lfloor|x|+\frac12\rfloor$ & away from zero\\
even  & $\mbox{even}(\lfloor x\rfloor) \ifso \lfloor x \rfloor
        : \lceil x \rceil$ & round to even\\
odd   & $\mbox{even}(\lfloor x\rfloor) \ifso \lceil x \rceil
        : \lfloor x \rfloor$ & round to odd (not used in practice)
\end{tabular}

None of these is rounding.  For that we need
\[\mbox{nearest} f x = d > \frac12 \ifso \lceil x \rceil :
 d < \frac12 \ifso \lfloor x \rfloor : f(x) \]
\noindent where
$ d = x - \lfloor x \rfloor $

This higher-order function can be combined with the seven conversions
above to make seven ``round to nearest'' modes such as nearest out
(banker's rounding) or nearest even (IEEE rounding).

The claim of this paper is that executable specifications are important
to find and correct mistakes.  Did you notice the mistake(s) above?
Neither did two pre-publication readers.  The problem is that rounding
$x$ to an even (odd) integer is not well defined when $x$ is an odd (even)
integer.  This issue was discovered by testing.  The solution for even
is simple: if $x$ is exactly equal to an odd integer, round it to the
nearest multiple of 4.  There is no sensible way to round 0 to an odd
integer, so we strike odd rounding from the list.

\section{Existing standards}

\subsection{ISO 10967 Language-independent arithmetic}

Roughly speaking, the three parts of LIA cover everything
in Fortran 95 and C99 and a little bit more.

We have to discuss ISO 10967 for two reasons: it is the
standard that is meant to serve as a reference for arithmetic
in programming languages, and it does define fixed point
numbers (but no operations on them).  Any definition of
fixed point arithmetic should be practically compatible with it.

Further, the 1998 edition provided axioms (though no evidence
that the system described was consistent with them) which could
serve as models for checking a fixed-point specification.

The Language-independent arithmetic standard has three parts.

\subsubsection{Part: 1 Integer and floating point arithmetic}
An integer data type $I$ has parameters {\it bounded}\subI{}
true if the set is finite, {\it minint}\subI{} being the
smallest value or $-\infty$, and {\it maxint}\subI{} being the
largest value or $\infty$.  If {\it bounded}\subI{} is true,
then {\it minint}\subI{} can be 0, -{\it maxint}\subI{}, or
-({\it maxint}\subI{}+1).  Curiously, while both signed and
unsigned bounded integers are allowed, unbounded integers
must be signed; ``unbounded natural numbers are not covered
by this document.''  The usual 6 comparison operations are
defined.

The arithmetic operations are {\it neg}\subI{} (unary negation),
{\it add}\subI{}, {\it sub}\subI{}, {\it mul}\subI{},
flooring division {\it quot}\subI{} and the corresponding
remainder {\it mod}\subI{}, {\it abs}\subI{},
and {\it signum}\subI{} taking values 1 and -1.  The 1998 edition
included {\it sign}\subI{} with values 1, 0, and -1, but that was
dropped.  The 1998 edition included
truncating division {\it div}${}^t_I$ and the corresponding
remainder {\it rem}${}^t_I$ and two additional remainder functions
{\it mod}${}^a_I$ and {\it mod}${}^p_I$, all of which were deleted
in the 2012 edition.

LIA-1 integer arithmetic must handle overflow by causing
an overflow indication.  This includes conversion to a
smaller integer type.  Wrapping arithmetic is covered in
part 2.

A floating point data type $F$ has parameters {\it r}\subF{}
(radix), {\it p}\subF{} (precision), {\it emax}\subF{} (largest
exponent), {\it emin}\subF{} (smallest exponent),
{\it denorm}\subF{} (whether IEEE-style subnormals are supported),
and {\it ice\_60559}\subF{} (whether $F$ conforms to the IEEE
standard).  The usual 6 comparison operations are defined,
taking care to dodge around infinities and NaNs.

Additional tests {\it isnegzero}\subF{}, {\it istiny}\subF{},
{\it isnan}\subF{}, and {\it issignan}\subF{} express tests that
cannot be done using ordinary comparison against zero.

Three sets of basic operations (rounding to nearest even, down,
or up) are defined if {\it denorm}\subF{} is true, just the
rounded to nearest set if {\it denorm}\subF{} is false.
The basic operations are {\it add}, {\it sub}, {\it mul},
{\it div}, and {\it sqrt}.

Some arithmetic operations are not sensitive to rounding
mode: {\it abs}\subF{}, two-valued {\it signum}\subF{},
the IEEE remainder {\it residue}\subF{}, {\it intpart}\subF{},
{\it fractpart}\subF{}, {\it succ}\subF{} (next higher),
{\it pred}\subF{} (next lower), and {\it ulp}\subF{}.

There are three conversions from floating point to integer:
{\it ceiling}${}_{F\rightarrow I}$,
{\it floor}${}_{F\rightarrow I}$, and
{\it rounding}${}_{F\rightarrow I}$.

Section 5.3.5 defines floating point to fixed point conversion
(for the sake of format conversions like C's {\tt \%.$n$f}) and in
passing defines unbounded fixed point types, with parameters
{\it r}\subD{} (radix), {\it d}\subD{} (``density'' = scale),
and {\it dmax}\subD{} (a positive element of $\cal R$ or
undefined).  Two sets are defined:
\begin{eqnarray*}
D^* &=& \{n/(r_D^{d_D}) | n \in {\cal Z}\}\\
D &=& D^* \mbox{if unbounded}\\
D &=& D^* \cap [-dmax_D,dmax_D] \mbox{if bounded}
\end{eqnarray*}
Three rounding functions {\it nearest}\subD{} (our nearest even),
{\it up}\subD{} (ceiling), and
{\it down}\subD{} (floor), all ${\cal R} \rightarrow D^*$, are
defined.  Conversion from floating point to fixed point and
from fixed point to floating point uses one of these rounding
modes just like the basic arithmetic operations.

However, fixed point exists in LIA {\it only} for I/O conversion;
there are no comparison or arithmetic operations on $D$.

Floating point arithmetic with truncation is conspiciously
absent from the 2012 edition of LIA-1.  What it describes is
accurately rounded arithmetic and the building blocks for
interval arithmetic.

\subsubsection{Part: 2 Elementary numerical functions}

This part was issued in 2001.  There are some slight ``continuity
errors'' due to the revision of LIA-1: {\it iec\_559}\subF{} is
now {\it iec\_60559}\subF{}, for example.  This is another example
of why standards need to be machine-checked.

The additional integer operations include maximum, minimum,
greatest common divisor, and least common multiple
of a pair or sequence, if $x\ge y$ then $x-y$ else 0 (diminish),
integer power (but broken for $0^0$ so of very little use),
floored shifting by a power of 2 or 10, floored square root,
divisibility, evenness, oddness, floored ({\it quot}\subI{},
{\it mod}\subI{}), rounded ({\it ratio}\subI{}, {\it residue}\subI{}),
and ceilinged ({\it group}\subI{}, {\it pad}) quotient and remainder.
(The {\it pad} operation is actually $\lceil x/y \rceil\times y - x$.)

There are also wrapping versions of {\it add}, {\it sub}, and
{\it mul}, plus ``overflow'' versions giving you the high bits
lost by wrapping so that multiprecision arithmetic can be written.

The additional floating point operations include maximum and
minimum of a pair or sequence, diminish,  conversion to integral
in floating form ({\it floor}\subF{}, {\it rounding}\subF{}, and
{\it ceiling}\subF{}) together with {\it *\_rest}\subF{} operations
providing the lost fraction parts exactly, square root (already
in part 1) and reciprocal square root.  There is an operation
for multiplying two floats giving a result in a wider format with
a single rounding, just right for dot product.

The elementary transcendental operations include raising a
floating point number to an integer or floating point power,
plus the usual exponential, logarithmic, trigonometric, and
hyperbolic functions in several forms.

\subsubsection{Part 3: Complex integer and floating point
arithmetic and complex elementary numerical functions}

This part was issued in 2006.  It defines imaginary and
complex integer and imaginary and complex floating point
data types, basic operations on them, and elementary
transcendental operations.  Maximum and minimum are extended
to imaginary but not to complex types.

Part 3 ends with recommended changes to some of the operations
defined in Part 2 ``so that the returned angle is for the
proper quadrant''.  Again this suggests that a standard on which
great care was taken might have benefited from testing.

\section{ISO/IEC/IEEE 60559:2011}

This is the standard for floating point arithmetic.
It is the ISO/IEC edition of IEEE 754:2008, which in
turn was an update of classic IEEE 754 arithmetic to
include decimal floating point.  It specifies
32-, 64-, and 128-bit binary formats that can hold about 7,
16, and 34 decimal digits respectively
and 64- and 128-bit decimal formats that can hold
16 and 34 decimal digits respectively (table 3.2).

It is common belief that IEEE 754 arithmetic is all but
universal.  However, few systems support 128-bit binary floats
(the popular ARM, x86, and x86-64 architectures do not; SPARC
does), and even fewer support decimal floating-point natively
(recent IBM z/Series and POWER machines do).

IEEE 754 originally defined four rounding modes, up, down, in,
and nearest even in our terminology.  The current standard
adds nearest out (banker's rounding).

\subsection{COBOL}

COBOL is one of the oldest programming languages still in use.
It was designed to support accounting applications on small
machines.  For example, the Siemens 3003, regarded as ``a large-scale
\dots computer'', had 8000 words of
storage; the COBOL 61 compiler for that machine needed 10 passes.
Brinch Hansen and House [ref] report that ``The major problem of
implementation turned out to be the numerous definition problems
created by the vagueness of the official Cobol report.''

One of the major features of COBOL from the beginning was its
use of decimal fixed point arithmetic rather than floating point.
Accounting applications required answers that were exact or
computed according to known rounding rules.  Binary integers
and floats were eventually adopted in 2002, but had been common
extensions for many years.

A number is characterised by (a) whether it is signed or not,
(b) its precision, and (c) its scale.  A declaration like\\
77 SOME-NUMBER PICTURE S9$(b)$V$9(a)$\\
declares a signed variable (S) with a precision of $b+a$
decimal digits and a scale of $a$.  The letter V designates
a virtual (not actually stored) decimal point.  In terms of
LIA-1, this corresponds to $r_D = 10$, $d_D = a$,
{\it dmax}${}_D = (10^{a+b}-1)/10^b$.

In LIA-1, arithmetic is only defined between values of the
same type.  In COBOL, it is extremely common for the
operands and result of an operation to be of different types.
A typical instruction is
\begin{tabbing}
www\=\kill
MULTIPLY X BY Y GIVING Z ROUNDED\\
\> ON SIZE ERROR {\it statements}\\
\>  NOT SIZE ERROR {\it statements}\\
END MULTIPLY
\end{tabbing}
\noindent where the product $X\times Y$ is computed
according to exact rational arithmetic, rounded to the
scale of $Z$, and if the result is too large to fit,
the ON SIZE ERROR statements are executed, otherwise
the result is stored in Z and the NOT SIZE ERROR
statements are executed.

\subsubsection{Four semantics for arithmetic}

The previous paragraph is a lie.  The current COBOL standard does not
offer a semantics for arithmetic.  It offers {\it four} semantics for
arithmetic.  A COBOL program may contain an OPTIONS paragraph near
the beginning:
\begin{tabbing}
www\=wwwwwwwwwwwwwwww\=\kill
OPTIONS.\\
\> [ARITHMETIC IS \{NATIVE $|$ STANDARD $|$\\
\> \> STANDARD-BINARY $|$ STANDARD-DECIMAL \}]\\
\> [DEFAULT ROUNDED MODE IS one of eight]\\
\> \dots\\
\> [INTERMEDIATE ROUNDING IS one of four]\\
\end{tabbing}

In our terminology, the rounding modes are out, nearest out,
nearest even, nearest in, exact, up, down, and in.

There is a subtle difference between these statements:
\begin{tabbing}
MULTIPLY X BY Y GIVING Z.\\
COMPUTE Z = X * Y.
\end{tabbing}
The latter involves an arithmetic expression which has an
intermediate result that is then assigned to the destination.
The former does not.  It appears that the MULTIPLY statement
involves a single rounding whereas the COMPUTE statement may
involve a double rounding.

{\it Native} arithmetic is whatever the implementor says it is.

{\it Standard} arithmetic is what used to be standard arithmetic in
COBOL-85.  It does not cover binary or floating-point operations,
which are treated as native.  Standard arithmetic is declared to
be obsolete.  ``A standard intermediate data item is \dots the
unique value zero or an abstract, signed, normalized decimal
floating-point temporary data item \dots with a precision of
32 decimal digits'' and a scale of -999 to 999 (roughly speaking).
Intermediate values are rounded in certain circumstances.

In expressions,
addition, subtraction, multiplication, and
division are are ``the exact [result] truncated
to 32 significant digits, normalized, and stored in a standard
intermediate data item''.

{\it Standard-binary} arithmetic requires arithmetic operations
to be done according to IEEE binary floating-point
arithmetic (128-bit format).

{\it Standard-decimal} arithmetic requires arithmetic operations
to be done according to IEEE decimal floating-point arithmetic
(128-bit format).

The result is that the meaning of an arithmetic statement or
expressions can be changed by a line thousands of lines away.

The standard tries very hard to avoid using
mathematical notation.  Let us take Format 5 of the
DIVIDE statement as an example:
\begin{quote}
\begin{tabbing}
www\=\kill
DIVIDE \{identifier-2$|$literal-2\} BY \{identifier-1$|$literal-1\}\\
\> GIVINE identifier-3 [rounded-prhase]\\
\> REMAINDER identifier-4\\
\> [ON SIZE ERROR imperative-statement-1]\\
\> [NOT SIZE ERROR imperative-statement-2]\\
\> [END-DIVIDE]
\end{tabbing}

1) When native arithmetic is in effect, the quotient is the result
of dividing the dividend by the divisor.  When standard arithmetic,
standard-decimal arithmetic, or standard-binary arithmetic is in
effect, the quotient is the result of the arithmetic expression
$$(\mbox{dividend} / \mbox{divisor})$$
where the values of dividend and divisor are ...

6b) The quotient is then formed as specified in general rule 1
and stored in identifier-3 \dots

6c) If the size error condition is not raised, a subsidiary
quotient is developed that is signed and derived from the
quotient by truncation of digits at the least significant end
and that has the same number of digits and the same decimal point
location as the data item references by identifier-3.  The
remainder is calculated as indicated in general rules 7 and is
stored in the data item referenced by identifier-4 unless
storing the value would cause a size error condition \dots

7) When native arithmetic is in effect, the remainder is the
result of multiplying the subsidiary quotient and the divisor
and subtracting the product from the dividend.  When standard
standard arithmetic, standard-decimal arithmetic, or
standard-binary arithmetic is in effect, the remainder is the
result of the arithmetic expression
$$(\mbox{divided} - (\mbox{subsidiary-quotient} * \mbox{divisor}))$$
where \dots
\end{quote}

The reason the standard {\it does} use some expressions here is
so that the rules for intermediate rounding apply to them.  With
4 arithmetics, 8 intermediate roundings, and 4 default roundings,
a simple DIVIDE statement could mean 128 different things.

\subsection{PL/I}

PL/I was introduced in the mid-1960s as a blend of Algol,
Fortran, and COBOL.  The ECMA-50 (1976), ANSI X3.53-1976, BS 7148:1990,
NF Z 65-500, and ISO 6160:1979 standards for PL/I are all basically the
same.  They have expired.  BS ISO/IEC 6522:1992 (Information technology,
Programming languages, PL/I general purpose subset) is still current.

PL/I fixed point types are characterised by a {\it base} (2 or 10),
a {\it precision} (total number of digits), and a {\it scale} (number
of digits after the radix point).  There are actually two sets of
rules for determining the precision and scale of a result (ANSI and
IBM).  For FIXED DECIMAL they coincide:
\begin{itemize}
\item
$(p_1,s_1) \pm (p_2,s_2) \Rightarrow (p,s)$ where\\
$s = s_1 \vee s_2$\\
$p = 1+s+(p_1-s_1 \vee p_2-s_2)$
\item
$(p_1,s_1) \times (p_2,s_2) \Rightarrow (p,s)$ where\\
$s = s_1 + s_2$\\
$p = 1+p_1+p_2$
\item
$(p_1,s_1) / (p_2,s_2) \Rightarrow (p,s)$ where\\
$s = N-p_1+s_1-s+2$\\
$p = N$ and $N$ is the implementation-defined maximum precision.
\item
MOD$((p_1,s_1), (p_2,s_2)) \Rightarrow (p,s)$ where\\
$s - s_1 \vee s_2$\\
$p = N \wedge (p_2 - s_2 + s)$.
\item
$(p_1,s_1) ** k \Rightarrow (p,s)$ where\\
$s = s_1\times k$\\
$p = (p_1 + 1) \times k - 1$, if $k$ is a literal integer.
\item
ROUND$((p_1,s_1), s) \Rightarrow (p,s)$ where\\
$s$ is given as the second argument\\
$p = 1 \vee (p_1-s_1+1-s \wedge N)$
\end{itemize}
The rule for division can lead to some nasty surprises.
For example, 25+01/3 yields 25.3333333333333 but
25+1/3 results in an overflow.  So there are special functions
ADD(x, y, p[, s]), SUBTRACT(x, y, p[, s]),  MULTIPLY(x, y, p[, s]),
DIVIDE(x, y, p[, s]),
computing a result to a specified precision and scale (default s = 0)
in a single rounding.  There is no version of MOD with precision and
scale parameters.  In assignment
statements, ``padding or truncation can occur on the left or the right.
If nonzero \dots digits on the left are lost, the SIZE condition is
raised.''  This means that a statement like\\
X = X * Y;\\
uses the ``in'' rounding mode.  Unlike COBOL, PL/I does not offer
control over rounding, not even using the special functions, so there is
no way to change this.

\subsection{SQL}

The ISO/IEC 9075-1:2003 standard, SQL 2003, part 1,
says in section 4.4.3.1 that ``There are two classes of numeric
type: {\it exact numeric}, which includes integer types and types
with specified precision and scale; and {\it approximate numeric},
which is essentially floating point, and for which a precision may
optionally be specified.''  The result of an arithmetic operation
``is of a numeric type that depends only on the numeric type of the
operands.  If the result cannot be represented exactly in the result
type, then whether it is rounded or truncated is implementation-defined.
An exception condition is raised if the result is outside the range of
numeric values of the result type, or if the arithmetic operation is not
defined for the operands.''

Numbers and arithmetic are defined in
section 4.4 of part 2.
\begin{quote}
`An exact numeric type has a precision
$P$ and a scale $S$.  $P$ is a positive integer that determines
the number of significant digits in a particular radix $R$,
where $R$ is either 2 or 10.  $S$ is a non-negative integer.
Every value of an exact numeric type of scale $S$ is of the
form $n\times 10^{-S}$,\footnote{It is possible that 10 should
have been $R$, but only INTEGER types with $S=0$ may have $R=2$.}
where $n$ is an integer such that $-R^P \le n < R^P$.
[Note 13 --- Not every value in that range is necessarily a
value of the type in question.]''
\end{quote}
The intent of note 13 may be to allow both sign-and-magnitude
representation for NUMERIC types and $R$'s-complement representation
for INTEGER types; it's not obvious why any other value would be
excluded.

Conversion may be done by rounding or truncation; it is not the
programmer who chooses.
\begin{quote}
``If an assignment of some number would result in a loss of its most
significant digit, an exception condition is raised.  If least
significant digits are lost, implementation-defined rounding or
truncating occurs, with no exception condition being raised.''

``An approximation obtained by truncation of a numeric value $N$ for an
$\langle$exact numeric type$\rangle$ $T$ is a value $V$ in $T$
such that $N$ is not closer to
zero than is $V$ and there is no value in $T$ between $V$ and $N$.

An approximation obtained by rounding of a numeric value $N$ for an
$\langle$exact numeric type$\rangle$ $T$ is a value $V$ in $T$
such that the absolute value of the difference between $N$
and the numeric value of $V$ is not greater than half
the absolute value of the difference between two successive numeric
values in $T$. If there is more than one such value $V$, then it is
implementation-defined which one is taken.''
\end{quote}

Aside from the non-portable nature of rounding,
arithmetic is supposed to be unsurprising:
\begin{quote}
``Operations on numbers are performed according to the normal
rules of arithmetic, within implementation-defined limits \dots''

``Numbers are compared with respect to their algebraic value.'' (8.2)
\end{quote}

Paraphrasing sections 4.4.3 and 6.26,
\begin{itemize}
\item The POWER function never returns an exact answer (unlike PL/I).
\item The floor and ceiling functions return exact integers $S=0$.
\item Unary plus, unary minus, and the absolute value function return a result
of the same type as their argument.
\item  The MOD function only accepts integer arguments.
\item WIDTH\_BUCKET$(x, l, u, n)$ appears to mean
\begin{tabbing}
www\=www\=\kill
if $l < u$ then\\
\> if $x<l$ then 0\\
\> else if $x \ge u$ then $n+1$\\
\> else $\lfloor n\times((x-l)/(u-l)) \rfloor$\\
else if $l > u$ then\\
\> if $x > l$ then 0\\
\> else if $x < u$ then $n+1$\\
\> else $\lfloor n\times((x-u)/(l-u)) \rfloor$\\
\end{tabbing}
and the result has the same type as $n$, which must be integral.
A system that can implement this function ought to be able to
implement MOD on non-integral exact numbers.
\item If $x$ has radix $R$, precision $P_x$, and scale $S_x$,
and $y$ has radix $R$, precision $P_y$, and scale $S_y$,
then $x+y$ and $x-y$ have scale max$(S_x,S_y)$ and
implementation-defined precision;
\item $x*y$ has scale $S_x+S_y$ and implementation-defined precision;
\item and $x/y$ has implementation-defined precision and
implementation-defined scale.
\item ``If the operator is not division and the mathematical result of
the operation is not exactly representable with the precision and scale
of the result data type, then an exception condition is raised.''
\item ``If the operator is division and the approximate mathematical
result of the operation represented with the precision and scale of the
result data type loses one or more leading significant digits after
rounding or truncating if necessary, then an exception condition is
raised \dots The choice of whether to round or truncate is
implementation-defined.''
\end{itemize}

COBOL and PL/I have fixed-point decimal types in order to support
accounting.
SQL was given fixed-point NUMERIC types in order to inter-operate
with COBOL and PL/I, and is very much used for accounting data.
The problem is that SQL arithmetic is {\it not} guaranteed
to be consistent with COBOL or PL/I or accounting rules:
\begin{itemize}
\item there is no programmer control over rounding;
\item there are no precisions that have to be supported,
not even older COBOL's 18 digits;
\item there is no fixed-point remainder; and
\item if you want to calculate the price of one
apple at \$2.72 per dozen, $2.72/12$ could give
you the answer 0 if an implementation defined the
scale for division to always be $S=0$.
\end{itemize}

\subsection{Smalltalk}

Smalltalk-80 is the programming language that brought Object-Oriented
programming and Integrated Development ENvironments to the world.
It got an ANSI standard in 1989.  The standard includes unbounded
integers, three sizes of floating point, rational numbers, and
a ScaledDecimal class.

For the semantics of operations on ScaledDecimal numbers,
the Smalltalk standard defers to ISO 10967 (LIA).  Unfortunately, LIA has,
by intent and quite explicitly, nothing to say about fixed point
arithmetic.

The result is that implementations use one of four interpretations
of ScaledDecimal:
\begin{itemize}
\item An arbitrary precision integer scaled by a power of 10.
This agrees well with the standard, which says that
``Scaled decimal objects provide a precise representation of decimal
fractions with an explicitly specified number of fractional digits.''.
\item An integer scaled by a power of 10, represented as a 16-byte
packed decimal value.  This also agrees well with the standard.
\item An arbitrary precision rational number that is not in general
a whole multiple of a power of 10, rounded to a specified number of
digits when and only when printing.
\item The same, but with truncation instead of rounding.
\end{itemize}
For example,
\begin{tabbing}
(2/3) asScaledDecimal: 2 $\Longrightarrow$ 0.66s2\\
``and'' 0.66s2 * 3 $\Longrightarrow$ 1.98s2\\
``but'' ((2/3) asScaledDecimal: 2) * 3 $\Longrightarrow$ 2.00s2
\end{tabbing}
in several Smalltalks (several others yield 0.67s2), while
\begin{tabbing}
(2/3) asScaledDecimal: 2 $\Longrightarrow$ 0.67s2\\
0.67s2 * 3 $\Longrightarrow$ 2.01s2\\
((2/3) asScaledDecimal: 2) * 3 $\Longrightarrow$ 2.01s2
\end{tabbing}
in Smalltalks using a scaled-integer interpretation.

% Standard: #+ #- #* #/ result scale is at least receiver scale.
% Majority rule: result scale is max(receiver scale, operand scale).
% astc: #+ #- => max(r,o); #* => r+o #/ ->
% astc: x \\ y = x - ((x // y) * y) => #- rule
%       x rem: y = x - ((x quo: y) * y) => #- rule.

\subsection{C$\sharp$}

Summary: decimal arithmetic is standard in C$\sharp$.
Such numbers are value types, as in COBOL and PL/I.
C$\sharp$ does not support sufficient precision or sufficient scale
to allow unproblematic conversion of COBOL 2002 code or
data, though it is adequate for COBOL 85.  There is no
programmer control over rounding.  Scale is part of the
value, not part of the type, and the rule for division
makes it hard to track scale at compile time.  Above all,
decimal arithmetic in C$\sharp$ is exact {\it except when
it isn't}.  The compiler will not tell you when unexpected
rounding {\it might} happen, nor does the runtime system
tell you when it {\it has} happened.

ISO/IEC 23270:2006 defines C$\sharp$ as it was in 2005.
ISO/IEC 23231:2012 defines the Common Language Infrastructure
The CLI standard omits the ``Extended numerics library'' (section
IV.5.7), including System.Decimal, but the language standard
has much to say.

Section 8.2.1 says
\begin{quote}
The {\tt decimal} type is appropriate for calculations in which
rounding errors caused by floating-point representations are
unacceptable.
\end{quote}

Except for rounding errors introduced silently by C$\sharp$ itself.

Section 11.1.7 defines the {\tt decimal} type.
\begin{quote}
The {\tt decimal} type is a 128-bit data type suitable for
financial and monetary calcuations.  The {\tt decimal} type
can represent values including those in the range $1\times 10^{-28}$
through $1\times 10^{28}$ with at least 28 significant digits.
The finite set of values of of type {\tt decimal} are of the
form $(-1)^s\times c\times 10^{-e}$, where the sign $s$ is 0 or 1,
the coefficient $c$ is given by $0\le c<Cmax$ and the scale $e$
is such that $Emin\le e\le Emax$, where $Cmax$ is at least
$1\times 10^{28}$, $Emin\le 0$, and $Emax\ge 28$.  The decimal
type does not necessarily support signed zeros, infinities, or
NaN's.

A {\tt decimal} is represented as an integer scaled by a power of
ten.  For {\it decimal}s with an absolute value less than {\tt 1.0m},
the value is exact to at least the 28${}^{th}$ decimal place.
For {\tt decimal}s with an absolute value greater than or equal to
{\tt 1.0m}, the value is exact to at least 28 digits.  Contrary
to the {\tt float} and {\tt double} data types, decimal fractional
values such as {\tt 0.1} can be represented exactly in the
{\tt decimal} representation.  In the {\tt float} and {\tt double}
representations, such numbers often have non-terminating binary
expansions, making those representations more prone to round-off errors.

The result of an operation on values of type {\it decimal} is that
which would result from calculating an exact result (preserving
scale, as defined for each operator) and then rounding to fit the
representation.  Results are rounded to the nearest representable
value, and, when a result is equally close to two representable
values, to the value that has an even number in the least significant
digit position (this is known as ``banker's rounding'').  That is,
results are exact to at least the 28${}^{th}$ decimal place.
Note that rounding may produce a zero value from a non-zero value.

If a {\tt decimal} arithmetic operation produces a result whose magnitude
is too large for the {\tt decimal format}, a
{\tt System.OverflowException} is thrown.

The {\tt decimal} type has greater precision but may have a smaller
range than the floating-point types.  Thus, conversions from the
floating-point types to {\it decimal} might produce overflow
exceptions, and conversions from {\tt decimal} to the floating-point
types might cause loss of precision or overflow exceptions.  For
these reasons, no implicit conversions exist between the floating-point
types and {\tt decimal}, and without explicit casts, a compile-time
error occurs when floating-point and {\tt decimal} operands are
directly mixed in the same expression.
\end{quote}

Section 14.7, ``arithmetic operators'', says
\begin{quote}
The scale of the result [of a decimal multiplication],
before any rounding, is the sum of the scales of the two operands.

The scale of the result [of a decimal division],
before any rounding, is the closest scale to the preferred scale which
will preserve a result equal to the exact result.  The preferred scale
is the scale of x less the scale of y.

The scale of the result [of a decimal remainder],
before any rounding, is the larger of the scales of the two operands,
and the sign of the result, if non-zero, is the same as that of [the
first operand].

The scale of the result [of a decimal addition or subtraction],
before any rounding, is the larger of the scales of the two operands.
\end{quote}

With the exception of division, the scale rules are familiar and
sensible. There is no division method that
takes a desired scale argument, unlike PL/I.

The scale rule for division appears to be intended to
ensure that scale($(x*y)/y$) = scale($x$), but if we take
{\tt 1.0m/3.0m} there is {\bf no} scale which ``will preserve a
result equal to the exact result'', and this is the case for almost
every possible division.  What you get is the highest supported scale
that doesn't result in an overflow.

There is no direct way to ask a {\tt decimal} for its scale,
but two numerically equivalent values can be operationally
distinguished:
\begin{tabbing}
1.0m.ToString() $\Longrightarrow$ "1.0"\\
1.00m.ToString() $\Longrightarrow$ "1.00"\\
4.0m/2.0m $\Longrightarrow$ 2\\
4.00m/2.0m $\Longrightarrow$ 2.0
\end{tabbing}

The remainder operator is the counterpart of the operation that
divides two decimal numbers giving an exact integer result.
There is no such operation.

The {\tt System.Decimal} class has methods {\tt Ceiling},
{\tt Round}, {\tt Floor}, and {\tt Truncate} which return exact
integer answers in {\tt decimal} form, no integer
type is certain to be large enough.  The Round method has
optional desired-scale and how-to-round-0.5 arguments,
supporting nearest out and nearest even.

% C$\sharp$ changes faster than ISO processes can keep up with.
% The current specification is C$\sharp$ version 6.0.

\subsection{Java}

Summary: decimal numbers in Java are a reference type,
{\tt java.math.BigDecimal}, not a primitive type.
There are no literals for this type nor
are the usual arithmetic operators available.
It is not described in the Java Language Specification.
However, full control over rounding is possible, and
Java gives exact results unless you ask for rounding.
It {\it is} possible to convert COBOL 2002 and data to
Java.  Any finite {\tt float} or {\tt double} value can
be represented exactly as a {\tt BigDecimal}.

There is no international standard for Java, but there is the
much-revised Java Language Specification
[https://docs.oracle.com/javase/specs/jls/se8/html/index.html]
and the Java Community Process for maintaining Java, which is not
entirely unlike a standards process.

The version of Java current at the time of writing was 1.8,
and that edition of the Java Language Specification has nothing to say
about {\tt BigDecimal}.

The Java API Online Reference
[https://docs.oracle.com/javase/8/docs/api/overview-summary.html]
says that
\begin{quote}
[{\tt BigDecimal}s are i]mmutable, arbitrary-precision
signed decimal numbers.  A {\tt BigDecimal} consists of an
arbitrary precision integer {\it unscaled value} and a 32-bit
integer {\it scale} [which may be positive, negative, or zero].
The value represented by [a] {\tt bigDecimal} is therefore
$(\mbox{unscaledValue} \times 10^{-\mbox{scale}})$.

The {\tt BigDecimal} class gives its user complete control over
rounding behavior.  If no rounding mode is specified and the exact
result cannot be represented, an exception is thrown; otherwise,
calculations can be carried out to a chosen precision and rounding mode
by supplying an appropriate {\tt MathContext} object to the operation.  In
either case, eight rounding modes are provided for the control of
rounding.

When a {\tt MathContext} object is supplied with a precision setting
0f 0 \dots, arithmetic operations are exact.  \dots In the case of
divide, the exact quotient could have an infinitely long decimal
expansion; for example, 1 divided by 3.  If the quotient has a
nonterminating decimal expansion and the operation is specified to
return an exact result, an ArithmeticException is thrown.  Otherwise,
the exact result of the division is returned, as done for other
operations.

Since the same numerical value can have different representations (with
different scales), the rules of arithmetic and rounding must specify
both the numerical result and the scale used in the result's
representation.

For all arithmetic operators, the operation is carried out as though an
exact intermediate result were first calculated and then rounded to the
number of digits specified by the precision setting (if necessary),
using the selected rounding mode.

Besides a logical exact result, each arithmetic operation has a
preferred scale for representing a result.

\begin{tabular}{|l|l|}
\hline
Operation | Preferred Scale of Result\\
\hline
Add | max(addend.scale(), augend.scale())\\
\hline
Subtract | max(minuend.scale(), subtrahend.scale())\\
\hline
Multiply | multiplier.scale() + multiplicand.scale()\\
\hline
Divide | dividend.scale() - divisor.scale()\\
\hline
\end{tabular}

\dots an exact divide may have to use a larger scale [when]
the exact result has more digits.

{\tt BigDecimal}'s {\it natural ordering} is
{\it inconsistent with equals}.
\end{quote}

The issue here is that {\tt compareTo} compares the algebraic
values of two {\tt BigDecimal}s, but {\tt equals} compares
their representations.

Quotient returning an integer in {\tt BigDecimal} form and
corresponding remainder are supported.

\subsection{Swift}

Summary: Swift supports decimal numbers with up to 38 digits
and a scale of -128 to 127.

Swift is a fast-changing language pushed by Apple.
At the time of writing the current version was Swift 3.

Swift 2 supported ``toll-free bridging'' to the Objective-C
type {\tt NSDecimalNumber}, ``[a]n instance [of which]
can represent any number that can be expressed as
mantissa
$\times$
$10^{exponent}$
where mantissa
is a decimal integer up to 38 digits long, and exponent is an
integer from -128 through 127.''

Swift 3 has a native {\tt Decimal} ``value type which offers
the same functionality as the {\tt NSDecimalNumber} reference
type, and the two can be used interchangeably in Swift code
that interacts with Objective-C APIs.''  Literals in integer
or floating-point form can be used where Decimal literals
are wanted, but they are first stored as Int or Float and
then converted to Decimal.

Swift {\tt Decimal}s include a NaN value but not infinities
or negative zero.

The {\tt NSDecimal} methods {\tt adding}, {\tt subtracting}, {\tt multiplying},
{\tt dividing}, and {\tt raising} have an optional
{\tt NSDecimalNumberBehavior} argument, like the corresponding
Java methods, which specifies a desired scale and rounding
mode, which can be up, down, in, or nearest out.
There is also {\tt NSDecimalNumberHandler} which can specify
what to do if an answer is inexact or overflows.
In Swift, there are methods {\tt add, +}, {\tt subtract, -},
{\tt multiply, *}, and {\tt divide, /} without control arguments
and NSDecimalAdd, NSDecimalSubtract, NSDecimalMultiply,
and NSDecimalDivide methods with RoundingMode parameter.

[The current state of the documentation for Swift 3 is
{\bf horrible}.  I'm having serious trouble finding
{\it anything} about how this all works.]

\end{document}