\chapter{Specification}\label{chap:specification}

Below ``$\log$'' means ``$\log_2$'', ``$\Vert$'' is string concatenation, all hash values are 32-byte. The type of tree used is a complete binary hash tree (i.e., a complete Merkle tree).

\section{Primitives}

\gravity requires three hash functions, which all return 32-byte hash
values:

\begin{itemize}

\item \hashx takes input values of any length. We use \textbf{SHA-256} as \hashx.

\item \hashy takes input values of 32 bytes. We use \textbf{Haraka-256} with 6 rounds as \hashy.

\item \hashz takes input values of 64 bytes. We use \textbf{Haraka-512} with 6 rounds as \hashz.

\end{itemize}
The Haraka versions are the v2~\cite{haraka}.

\gravity also uses \textbf{AES-256-CTR} as a deterministic generator of pseudorandom bytes.

\section{Parameters}

\gravity signature schemes are defined by three parameters:

\begin{itemize}

\item The \textbf{set size} $T$, which must be a power of two.

\item The \textbf{subset size} $K$, which must be lower than $T$.

\item The \textbf{number of subtrees} $C$, which must be a power of two and strictly lower than $T$.

\end{itemize}

These parameters determine:

\begin{itemize}

\item The \textbf{public key size}, equal to $32C$ bytes.

\item The \textbf{signature size}, equal to $32\times (K + K(\log T- \log C)+1)$ bytes.

\end{itemize}

$T$ and $K$ together determine the security and signature length, while $C$ determines the public key and signature lengths but not security.

The choice of $T$ and $K$ depends on the target security security level and on the maximum number of messages to be signed.
The security level for a given $(T,K)$ is discussed in \S\ref{sec:attacks}.

The choice of $C$ is mostly a trade-off between the public key size (higher with a higher $C$) and the  signature size (smaller with a higher $C$).
The optimal value of $C$ for a given $(T,K)$ is discussed in \S\ref{sec:tradeoff}.

\section{Key Generation}

A secret key \sk is a random 64-byte value, viewed as two 32-byte values $\sk_1\Vert\sk_2=\sk$.

A public key \pk is derived from a secret key's $\sk_1$ as follows:

\begin{enumerate}

\item Expand \sk into $T$ 32-byte \emph{subkeys} $\ek_0, \ek_1, \dots, \ek_{T-1}$, by taking the first $32T$ bytes generated with AES-256-CTR keyed with $\sk_1$ and with a 16-byte counter initialized to \hex{0000\dots0000}.

\item Hash each subkey to obtain $T$ values $L_i=\hashy(\ek_i)$, $i=0,\dots,T-1$, which will be the leaves of the tree.

\item Compute $\pk = \pk_0, \cdots, \pk_{C}$ as the $C$ nodes on level $\log C$ of the binary hash tree with leaves $L_0, \dots, L_{T-1}$, computing $\hashz(L_0\Vert L_1)$, $\hashz(L_2\Vert L_3)$, and so on.

\end{enumerate}

Step 1 requires $32T$ bytes from \drbg, step 2 requires $T$ calls to $\hashy$, and step 3 requires $T - C$ calls to $\hashz$.

The value $\log C$ can be seen as the ``cut-off'' level of the tree.

The $\sk_2$ component of the secret key is not used in key generation, but only when signing a message.

\section{Subset Generation}\label{sec:subsetgen}

The core component of \gravity is its \emph{subset generation function}, which picks $K$ distinct values in $0, 1, \dots, T-1$ given a 32-byte \emph{signature seed} $S$ and $H = \hashx(M)$, the 32-byte hash of the message.

Subset generation works like this:

\begin{itemize}

\item Compute the \emph{subset seed} $D=\hashz(S\Vert H)$.

\item Generate pseudorandom bits from \drbg keyed with $D$ and with a 16-byte counter initialized to \hex{0000\dots0000}.

\item Parse the pseudorandom stream as a sequence of 4-byte big-endian unsigned integers $N_0, N_1, N_2, \dots$, where each integer is reduced modulo $T$ (since $T$ is a power of two, the distribution remains uniform)

\item Determine the $K$ distinct values $V_0,\dots,V_{K-1}$  as follows: $V_0=N_0$; $V_1$ is the first $N_i, i>0$ such that $N_i\neq V_0$; third value is the first subsequent $N_i$ distinct from both $V_0$ and $V_1$, and so on.

\end{itemize}

\section{Signing a Message}

Given a secret key $\sk=\sk_1\Vert \sk_2$ and a message $M$, \gravity computes a signature $\sig$ as follows:

\begin{enumerate}

\item Generate a subset of indices $V_0, V_1,\dots,V_{K-1}$ as per \S\ref{sec:subsetgen}, using $S=\hashz(\sk_2 \Vert \hashx(M))$ as signature seed. Initialize the signature with the 32-byte $S$.

\item Expand $\sk_1$ into $T$ 32-byte \emph{subkeys} $\ek_0, \ek_1, \dots, \ek_{T-1}$ in the same manner as for public key generation.

\item Append $K$ subkeys to the signature in order to have $\sig= S \Vert \ek_{V_0}\Vert \ek_{V_1}\Vert \cdots \Vert \ek_{V_{K-1}}$.

\item Compute the binary hash tree up to level $1 + \log C$ like for public key generation, but recording the \emph{authentication paths} for each of the $K$ leaves from the subset, as follows:
\begin{enumerate}
\item Hash each subkey to obtain leaves hashes $L_i=\hashy(\ek_i)$, $i=0,\dots,T-1$.
\item Append to $S$ the leaf value to be hashed together with $L_{V_0}$, then the leaf value to be hashed together with $L_{V_1}$, and so on until $L_{V_{K-1}}$.
\item Compute the parent node of each consecutive pair of leaves by doing $\hashz(L_0\Vert L_1)$, $\hashz(L_2\Vert L_3)$, and so on. Append to $S$ the sibling hash value for each of the $K$ parents of a subkey, from $V_0$ to $V_{K-1}$; $K$ hashes are thus appended to $S$.
\item Iterate step (c) for upper levels of the tree, appending sibling nodes to $S$ to form $K$ authentication paths, until level $1 + \log C$ (that is, one level deeper than the level of the subtrees' roots in the public key).
\end{enumerate}
\end{enumerate}
The signature $\sig$ eventually contains, in this order: the signature seed, the $K$ hashes from step 3, and the $K(\log T - \log C)$ hashes from step 4.

Step 1 requires one call to $\hashx$, two calls to $\hashz$, and at least $4K$ bytes from \drbg; step 2 requires $32T$ bytes from \drbg; step 4.a requires $T$ calls to $\hashy$, then iterating step 4.b-d requires $T-C$ calls to $\hashz$.

\begin{figure}
\includegraphics[width=16cm]{sig}
\caption{Content of a signature.}
\end{figure}

\section{Verifying a Signature}

Given a public key \pk and a message $M$, \gravity verifies a signature $\sig$ as follows:

\begin{enumerate}

\item Generate a subset of indices $V_0, V_1,\dots,V_{K-1}$ as per \S\ref{sec:subsetgen}, using the first 32 bytes of \sig as a signature seed.

\item For each of the $K$ indices:
\begin{enumerate}

\item Retrieve the subkey from the signature, where the subkey of index $V_i$ is the $i$th 32-byte string in the signature.

\item Using the authentication path in the signature (every other $K$ hash after the signature seed), compute parent nodes up to level $\log C$.

\item Check if the subtree root found at level $\log C$ is the same as in the public key.

\end{enumerate}
\item Verification of $\sig$ is successful only and only if all $K$ verifications succeeded.
\end{enumerate}

Step 1 requires one call to $\hashx$ and one call to $\hashz$, and at least $4K$ bytes from \drbg; step 2 requires $K$ calls to $\hashy$ and $K (\log T- \log C)$ calls to $\hashz$.

\begin{figure}
\includegraphics[width=16cm]{tree}
\caption{Binary hash tree of a signature, with a set of $T=8$ hashes (thus a tree depth of $\log T=3$), a subset of $K=2$ hashes, $C=2$ subtrees (thus their two respective roots in the public key), and subset of indexes $V_0=2, V_1=5$. The nodes in black are part of the signature, the nodes in pale grey are computed during the verification, and the nodes in dark grey are part of the public key.
}
\end{figure}

\section{Proposed Instances}

See Table~\ref{tab:instances}.

\begin{table}
\centering
\begin{tabular}{c|ccc|c|ccc}
\toprule
\multirow{2}{*}{ID} & \multicolumn{3}{c|}{Parameters} & Messages & \multicolumn{3}{c}{Byte length} \\
& $T$ & $K$ & $C$ & limit & Sig & Pub & Priv \\
\midrule
S & $2^{17}$ & 54 & $2^{6}$ & 100 & $\num{20768}$ & 2048 & 64 \\
M & $2^{18}$ & 62 & $2^{7}$ & 300 & $\num{23840}$ & 4096 & 64 \\
L & $2^{19}$ & 64 & $2^{7}$ & 600 & $\num{26656}$ & 4096 & 64 \\
\bottomrule
\end{tabular}
\caption{Proposed \gravity instances, expected to provide 128-bit pre- and post-quantum security.}
\label{tab:instances}
\end{table}


\documentclass[preprint]{sigplanconf}

\usepackage{graphicx}
\usepackage{longtable}
\usepackage{comment}
\usepackage{amsmath}
\usepackage{mdwlist}
\usepackage{txfonts}
\usepackage{xspace}
\usepackage{amstext}
\usepackage{amssymb}
\usepackage{stmaryrd}
\usepackage{proof}
\usepackage{multicol}
\usepackage[nodayofweek]{datetime}
\usepackage{etex}
\usepackage[all, cmtip]{xy}
\usepackage{xcolor}
\usepackage{listings}
\usepackage{multicol}
\usepackage{bm}

\newtheorem{theorem}{Theorem}[section]
\newtheorem{lemma}[theorem]{Lemma}
\newtheorem{proposition}[theorem]{Proposition}
\newtheorem{corollary}[theorem]{Corollary}

\newcommand{\xcomment}[2]{\textbf{#1:~\textsl{#2}}}
\newcommand{\amr}[1]{\xcomment{Amr}{#1}}
\newcommand{\roshan}[1]{\xcomment{Roshan}{#1}}

\newcommand{\ie}{\textit{i.e.}\xspace}
\newcommand{\eg}{\textit{e.g.}\xspace}

\newcommand{\lcal}{\ensuremath{\lambda}-calculus}
\newcommand{\G}{\ensuremath{\mathcal{G}}\xspace}

\newcommand{\code}[1]{\lstinline[basicstyle=\small]{#1}\xspace}
\newcommand{\name}[1]{\code{#1}}

\def\newblock{}

\newenvironment{floatrule}
    {\hrule width \hsize height .33pt \vspace{.5pc}}
    {\par\addvspace{.5pc}}

%subcode-inline{bnf-inline} name langRev
%! swap+ = \mathit{swap}^+
%! swap* = \mathit{swap}^*
%! dagger =  ^{\dagger}
%! assocl+ = \mathit{assocl}^+
%! assocr+ = \mathit{assocr}^+
%! assocl* = \mathit{assocl}^*
%! assocr* = \mathit{assocr}^*
%! identr* = \mathit{uniti}
%! identl* = \mathit{unite}
%! dist = \mathit{distrib}
%! factor = \mathit{factor}
%! (o) = \fatsemi
%! (;) = \fatsemi
%! (*) = \times
%! (+) = +

%subcode-inline{bnf-inline} regex \{\{(((\}[^\}])|[^\}])*)\}\} name main include langRev
%! Gx = \Gamma^{\times}
%! G = \Gamma
%! [] = \Box
%! |-->* = \mapsto^{*}
%! |-->> = \mapsto_{\ggg}
%! |--> = \mapsto
%! |- = \vdash
%! ==> = \Longrightarrow
%! <== = \Longleftarrow
%! <=> = \Longleftrightarrow
%! <-> = \leftrightarrow
%! ~> = \leadsto
%! -o = \multimap
%! ::= = &::=&
%! /= = \neq
%! forall = \forall
%! exists = \exists
%! empty = \epsilon
%! langRev = \Pi
%! langRevT = \Pi^{o}
%! langRevEE = \Pi^{\eta\epsilon}
%! theseus = Theseus
%! * = \times

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{document}

\conferenceinfo{ICFP'12}{}
\CopyrightYear{}
\copyrightdata{}
\titlebanner{}
\preprintfooter{}

\title{Functional Pearl --- Programming with \\
  Negative, Fractional, Square Root, and Imaginary Types}
\authorinfo{Roshan P. James}
           {Indiana University}
           {rpjames@indiana.edu}
\authorinfo{Amr Sabry}
           {Indiana University}
           {sabry@indiana.edu}
\maketitle

\begin{abstract}
  Every functional programmer knows about sum and product types, $a+b$ and
  $a*b$ respectively. Negative, fractional, square root, and imaginary types,
  $a-b$, $a/b$, $\sqrt{a}$, and $a+ib$ respectively, are much less known and
  their computational interpretation is unfamiliar and often complicated. We
  show that in a programming model in which information is preserved (such as
  the model introduced in our recent paper on \emph{Information Effects}),
  these types have particularly intuitive and natural computational
  interpretations. Intuitively, values of negative types are values that flow
  ``backwards'' to satisfy demands, values of fractional types are values
  that represent first-class ``structural'' constraints, and values of square
  root and imaginary types are values that can be related by arbitrary
  algebraic constraints. The combination of these negative, fractional,
  square root, and imaginary types enable greater flexibility in programming
  by breaking complicated invariants into local ones that can be
  independently satisfied by a subcomputation. Furthermore, they allow a
  programmer to express a wide range of programming idioms, including
  higher-order functions, delimited continuations, speculative computation,
  logic programming, and more.
\end{abstract}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\category{D.3.1}{Formal Definitions and Theory}{}
\category{F.3.2}{Semantics of Programming Languages}{}
\category{F.3.3}{Studies of Program Constructs}{Type structure}

\terms
Languages, Theory

\keywords continuations, information flow, linear logic, logic programming,
quantum computing, reversible logic, symmetric monoidal categories, compact
closed categories.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Introduction}

The world of computation we are describing has:
\begin{itemize}
\item suppliers,
\item consumers, and
\item bi-directional transformations
\end{itemize}
This is the same world described by the papers on the duality of computation
but that work only scratched the surface! We have the following features:
\begin{itemize}
\item we can start from the supplier and push the values towards the
  consumer (call-by-value in the duality of computation papers)
\item we can start from the consumer and pull the values from the suppliers
  (call-by-name in the duality of computation papers)
\item we can combine the pushing and pulling and values using eta/epsilon for
  sum types; these allow us to at any point in the middle of the computation
  create out of nothing a value to send to the consumers and a demand to send
  to the suppliers.
\item we can break a big data structure into fragments described by
  fractional types; the suppliers and consumers can produce and consume the
  pieces completely independently of each other. Eventually the pieces will
  fit together at the consumer to produce the desired output.
\item we can break a bi-directional transformation into pieces using square
  roots
\item we can take into account that values have phase (complex numbers),
  i.e., it is not that they flow towards the consumer or just towards the
  suppliers; they can be flowing in direction that ``30 degrees'' towards the
  consumer for example.
\end{itemize}
So it is all about breaking dependencies in some sense to allow for maximum
autonomy (parallelism) of subcomputations. It is probably the case that to
make full use of square root types and imaginary types, we have to move to a
vector space. If that's the case, we should probably leave this stuff out and
focus on negative and fractional types and only have a short discussion of
the polynomials restricted to seven trees in one and similar issues.

The conventional idea is to divide the world into a ``real'' one and a
``virtual'' one. In the ``real'' world, we can define datatypes like
\verb|t=t^2+1| but we don't have additive inverses so it makes no sense to
talk of negative types and we can't rearrange the terms in the datatype
definition. However the observation is that we can map these datatypes to a
virtual world that has more structure (a ring that provides additive inverses
or a field that also provides multiplicative inverses) and then perform
computations in the ring/field. If we perform computations in the ring, then
some of these will use additive inverses in ways that cannot be mapped back
to the ``real'' world. Much of current research attempts to characterize
which computations done in the ring are valid isomorphisms between datatypes
in the ``real'' world. This is nice but is not what I am after. In fact I am
not interested in the ring or the semiring at all. I am interested in the
field and I want this field to be \textbf{the real world.} This is partly
motivated by the fact that Quantum Mechanics seems to demand an underlying
field and more generally that the field provides the maximum generality in
slicing and dicing computations. So assuming I live in a field and that the
negative, fractional, square root, and imaginary types are all ``real,'' how
do I compute in this field? Clearly there will be constraints on
``measurement'' in the sense that a full program cannot produce any of the
crazy types but that's done outside the formalism in some sense just as in
Quantum Computing. The main question I am after is how to compute in this
field with first-class negative, fractional, etc. types. As I mentioned in my
previous email, we can produce programs that have types \verb|t^3 <-> -1| and
they ``run'' (but only to give infinite loops).

So when a programmer writes the datatype declaration \verb|t = t^2+1|, if we
allow negative etc. then this is effectively writing
\verb|t = cubicroot{-1}|. If we are in the field then computations that
manipulate these trees can be sliced and diced even at interfaces that
expose the cubic root and the imaginary types.

Future work: develop a type system for a ``normal language'' that has
negative, fractional, etc. types as first-class types. More long term,
instead of adding one polynomial at a time, we can go to an algebraically
closed field. The complex numbers is an obvious choice but I would rather go
to something computable like the field of algebraic numbers. Is the adele
ring or the p-adics relevant here?

We show a deep symmetry between functions and delimited continuations,
values and continuations that arises in {{langRev}} in a manner that
is reminiscent of Filinksi's Symmetric \lcal
~\cite{Filinski:1989:DCI:648332.755574}. The symmetry arises by
extending {{langRev}} with a notion of additive duality over the
monoid {{(+, 0)}} by including {{eta}} and {{eps}} operators of
Compact Closed Categories. The resulting dual types, which we denote
{{-b}}, have a time traveling ``backward information flow''
interpretation and allow for the encoding of higher-order function and
iteration via the construction of {{trace}} operators, thereby making
the extended language {{langRevEE}} a Turing-complete reversible
programming language with higher-order functions and first-class
delimited continuations.

We introduced this thesis that computation should be based on isomorphisms
that preserve information~\cite{infeffects}. Since Filinski, we've had the
idea that values and continuations are like mirror images. In a conventional
language, the negative (continuation) side is implicit and we introduce
information effects on the positive. Trying to recover the duality from this
distorted positive side has always been messy. Now it looks clean because we
have kept the positive side pure.

The way to think about something of type $A$ is that it is a value we have
produced. The way to think about something of type $-A$ is that is a value we
have already consumed.

Other interpretations of the types of think about. The first one is
arithmetic obviously. Another one is languages consisting of sets of
string. The type 0 is the empty set, the type 1 is the set containing the
empty word, the $+$ constructor corresponds to union, and the $*$ constructor
corresponds to concatenation. The constructor $-$ would not correspond to set
difference however. It would correspond to marking the elements in the set as
``consumed'' so that if we take the union and a ``consumed'' element appears
in the other set, the two cancel. This makes it clear that concatenating a
produced $a$ and a consumed $b$ is not the same as concatenating a consumed
$a$ and a produced $b$. They really need to be kept separate. Incidentally,
division would be defined as follows:
\[
L_1 / L_2 = \{ x ~|~ xy \in L_1 \mbox{~for~some~} y \in L_2 \}
\]

Connections to type logical grammars and Lambek calculus

Some background on {{langRev}} because it is mentioned in the next section.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Negative Types: Intuition}

Consider the following two ways of purchasing an item that costs \$20.00:
\begin{enumerate}
\item You give the seller a \$20.00 bill.
\item You use a credit card to pay the seller.
\end{enumerate}
In both cases, the seller receives the money immediately but there is a
subtle difference. In the first transaction, the money received by the seller
corresponds to a value that has been produced earlier in the computation. In
the second transaction, the money may or may not exist yet: computationally,
a \emph{debt} is generated to compensate for the money received by the seller
and this debt travels ``backwards'' towards the bank where it is (hopefully)
reconciled.

The example suggests that the ability to consider values flowing backwards
enriches our computational model. This observation goes back to Filinski's
Masters thesis where continuations are identified with these negative values.
We discuss the connections to Filinski's work and others in more detail in
Sec.~\ref{sec:related}. For now, we note that in a conventional programming
language in which values can be copied and deleted at will, extreme care is
needed to keep track of negative values. Indeed, in the example above, if it
were possible to simply delete the variable corresponding to the debt, we
would have produced money out of nothing.

For this reason, our treatment of negative values in the context of
{{langRev}} is particularly simple. We will have a type $0$ and an
isomorphism {{0 <-> a + (-a)}} that when used in the left-to-right direction
allows us to create a value and a corresponding debt out of nothing. Both the
value and its negative counterpart can flow anywhere in the system. Because
information is preserved, a closed program (which does not have any
``dangling'' negative values) will eventually have to match the negative
value with some corresponding value, effectively using the isomorphism in the
right-to-left direction. In more detail, we can model the credit card
transaction above using the following program (shown diagrammatically):

FIGURE

CLEAN UP the following based on the figure. In contrast, in our setting, one
can start from the empty type $0$, introduce a positive value and its
negative counterpart, and let each of these flow in arbitrary ways. The
entire framework guarantees that neither the value nor its negative
counterpart will be deleted or duplicated and hence that, in any closed
program, the ``debt'' corresponding to the negative value is paid off exactly
once. Computationally we model the first transaction using essentially the
identity function which receives a \$20.00 bill as input from the buyer and
propagates it on its output to the seller. The second transaction is more
complicated. We model it as shown in the circuit below: There are two ways to
understand this circuit that are both quite instructive. Let's first examine
the type structure of each of the combinators that comprise the circuit. The
first combinator on the right outputs \$20.00 to the seller. This \$20.00 is
produced from nothing so to speak by generating an equivalent debt that
travels backwards. COMPLETE BASED ON THE FIGURE. The other way is to follow
the execution. It goes forward in time so to speak, comes back, and then goes
forwards again.

It is critical that the framework in which the negative types are introduced
is a framework in which all information is preserved, with no duplication or
erasure. This guarantees that the generated debts are paid once and exactly
once.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Fractional Types: Intuition}

The type $a/b$ is prominent in the Lambek-Grishin calculus which is
extensively used in computational linguistics. In the common interpretation,
a value of type $a/b$ is a value of some type $c$ such that when put in a
context of type $b$, the result is a value of type $a$. For example, assuming
contexts are represented as functions, a value of type $\texttt{bool} /
(\texttt{int} \rightarrow \texttt{bool})$ is simply a value of type
$\texttt{int}$. Indeed in this case, putting a value of type $\texttt{int}$
in the context $(\texttt{int} \rightarrow \texttt{bool})$ produces a value of
type $\texttt{bool}$.

In our case, the situation is simpler. If the goal is to produce a value of
type {{a * b}} and a subcomputation can only produce the {{a}}-part, it would
have type {{(a * b) / b}}. In most settings, this type would be equivalent to
{{a}}. However in our setting, the constraint that this value must eventually
fit in a larger value that supplies the {{b}} is explicitly recorded and must
be resolved. In more detail, we have an isomorphism {{ 1 <-> a * (1/a) }}
which when used in the left-to-right direction allows the creation of a value
and a corresponding constraint on the context.  Both the value and the
constraint can flow in arbitrary ways during the computation but eventually
in a closed program with no ``dangling'' constraints, the isomorphism should
be used in the right-to-left direction to resolve the constraints.  To
understand the computational interpretation, consider the following example.

The goal is to produce a value of type $(\texttt{bool} \times
\texttt{int})$. One part of the program, $e_1$, knows how to produce the
value of type $\texttt{int}$ (say {{3}}) and another part, $e_2$, knows how
to produce the value of type $\texttt{bool}$ (say {{true}}). Computationally,
we model this as follows. The first subcomputation $e_1$ produces {{((),3)}}
and uses the isomorphism to convert {{()}} to {{(alpha,1/alpha)}} where
{{alpha}} is a yet-unknown boolean value. Reshuffling the components, $e_1$
produces {{((alpha,3), 1/alpha)}}. Similarly, $e_2$ can independently produce
{{((true,beta),1/beta)}} where {{beta}} is a yet-unknown integer value.
When the two values meet, we can group the components as follows:
\[
{{(alpha,beta)}}  {{(3,1/beta)}}  {{(true,1/alpha)}}
\]
Using the isomorphism in the right-to-left direction on the last two pairs,
forces {{alpha}} to be resolved to {{true}} and forces {{beta}} to be
resolved to {{3}}. Both of these pairs then become {{()}} and be absorbed. We
are left with the pair {{(true,3)}} as desired.

To summarize, one can think of a value of type $a/b$ as a value that imposes
a constraint on its context of use: it is a value that requires its context
to be of type $b$ and only if that condition is satisfied, can the value be
considered as a value of type $a$. In the simplest case, the type $1/b$ just
constraints the context to be of type $b$. By allowing the fractional types
to be first-class, we can separate the generation of constraints from their
use. Both the value and the constraint can flow in arbitrary ways during the
computation but eventually in a closed program with no ``dangling''
constraints, the isomorphism should be used in the right-to-left direction to
resolve the constraints.

NEED to work out the example in detail (or perhaps another example that's
better.

Again it is critical that the framework in which the fractional types are
introduced is a framework in which all information is preserved, with no
duplication or erasure. This guarantees that the generated constraints are
satisfied once and exactly once.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Algebraic Types: Intuition}

Square root and imaginary types have also appeared in the literature: we
relegate the connections to Sec.~\ref{related} and proceed with a simple
explanation. We have so far extended the set of types to be the rational
numbers. Now we will push this and extend the set of types to algebraic
numbers. In other words, we will allow datatypes defined by arbitrary
polynomials and allow the roots of such polynomials to be types.

Consider first an example in which we want to compute with the sides of a
rectangle whose area is 91 and whose length is longer than its width by 6
units. One can solve the quadratic equation to determine that the sides are 7
and 13 and proceed. This however prematuraly forces us to globally solve the
constraint. Instead we can let the two sides of the rectangle be $x$ and
$x+6$ and use the following equation to capture the desired constraint:
\[
x^2 + 6x - 91 = 0
\]
The equation introduces an isomorphism between the type $x^2 + 6x - 91$ and
the type $0$. We can now proceed to compute with the unknown $x$, being
assured that in a closed program, our computation will eventually be
consistent with the solution of the algebraic equation.

Previously the most famous example of a similar nature is the puzzling
isomorphism that one can establish between seven binary trees and one.
A binary tree is defined by the datatype
\[
x = 1 + x * x
\]
which can be rearranged to the polynomial equation $x^2 - x + 1 = 0$. By
algebraic manipulation we can reason as follows:
\[\begin{array}{rclclclcl}
x^3 &=& x^2 x &=& (x-1) x &=& x^2 - x &=& -1 \\
x^6 &=& 1 \\
x^7 &=& x^6 x &=& x
\end{array}\]
Fiore poses the question of why such algebraic manipulation would make sense
type theoretically but states that even though some of the intermediate steps
make no sense, the final equivalence is valid and can be used to actually
construct an isomorphism between $x^7$ the type of seven binary trees
and $x$ the type of binary trees.

Discussion of possible polynomials:
\begin{itemize}
\item $b=1+1$. Boring.
\item $b=b+1$. That introduces the natural numbers. No solution for this
  polynomial over the algebraic numbers. We must extend the numbers with
  $\omega$ to get a solution. We reject this in this paper and prefer to
  stick to algebraic numbers. The advantage is that all the isomorphisms are
  valid numerically. With the above type we could subtract $b$ from both
  sides to show that $0=1$ which is nonsense. We can however have infinite
  types as long as they have algebraic solutions.
\item $b^2=2$ or $b = \pm \sqrt{2}$. We have introduced the square root of a
  boolean! If we had superpositions, we could then write a function that
  performs the square root of negation in the sense that applying it twice
  would be equivalent to boolean negation.
\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Summary}

To summarize negative, fractional, square root, and imaginary types all make
sense. What they help you accomplish as a programmer is to disassociate
global invariants into local ones that can be satisfied independently by
subcomputations with no synchronization or communication. A computation
producing something of type $a/b$ does not need to concern itself with who is
going to supply the missing $b$: it just does its part. Conversely faced with
a complicated task, a computation might decide to break it into pieces and
demand these pieces using negative types.

It is no surprise that these types are closely related to quantum mechanics
and that they give us the feel that this is how nature computes. This is
speculation however.

In any case, in a framework where information can be copied and deleted, none
of this makes much sense. It is critical that these constraints and demands
can neither be duplicated nor erased.  This gives us the maximum
``parallelism'' possible.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Additive Duality in {{langRev}} }

%%%%%%%%%%%%%%%
\subsection{Syntax}

%subcode{bnf} include main
% Values, v = () | (v, v) | L v | R v
% Combinators, c &=& iso | c (;) c | c(+)c | c (*) c
%
% Sequential Contexts, P, F = [] | P:c
% Parallel Contexts, D = []
%                     &|& D:(P| [](+)c| F)
%                     &|& D:(P| c(+)[]| F)
%                     &|& D:(P| [] (*) c v| F)
%                     &|& D:(P| [] (*) v c| F)
%                     &|& D:(P| c v (*)  []| F)
%                     &|& D:(P| v c (*) []| F)
%
%
% Machine States  = D[P| c v| F] | D[P| v c| F]
% Start State  = [][[]| v c| []]
% Stop State  = [][P| c v| []]

Combinator reconstruction, {{P[c]}}:
%subcode{opsem} include main
% [](c) '= c
% P:c'(c) '= P(c'(;)c)

%%%%%%%%%%%%%%%%%%%%%
\subsection{Operational Semantics}

The small step semantics present for {{langRev}} below work
symmetrically for forward and backward evaluation.

\begin{itemize}
\item
Basic reduction of an isomorphism. Note that the evaluation leaves the
adjoint of the combinator behind. This will become important when we
reverse the direction of computation.
%% %subcode{opsem} include main
%% % <P; F; iso v; D>      &|-->& <P; F; v'~ iso{dagger}; D>

%subcode{opsem} include main
% D[P|v iso| F]      &|-->& D[P| iso{dagger} v| F]

\item
Sequencing involves pushing and popping from the Future and Past
continuations:
%subcode{opsem} include main
% D[P|v (c1(;)c2)| F]  &|-->& D[P| v c1| F:c2]
% D[P| c1 v| F:c2] &|-->& D[P:c1| v c2| F]

\item
Parallel composition, captures the current Future and Past and extends
the parallel context.
%subcode{opsem} include main
% D[P|(L v) c1 (+) c2| F] &|-->& D:(P|[](+)c2|F)[ []| v c1| [] ]
% D[P| (R v) c1 (+) c2| F] &|-->& D:(P|c1(+)[]|F)[ []| v c2| [] ]
% D:(P|[](+)c2|F)[P'|c1 v| [] ]  &|-->& D[P|(P'(c1)(+)c2{dagger}) (L v)| F]
% D:(P|c1(+)[]|F)[P'| c2 v| [] ] &|-->& D[P|(c1{dagger}(+)P'(c2)) (R v)| F]

\item
Similarly for products:
%subcode{opsem} include main
% D[P| (v1, v2) c1 (*) c2| F] &|-->& D:(P| [] (*) v2 c2|F)[ []| v1 c1| [] ]
% D:(P|[] (*) v2 c2|F)[P'| c1 v1| [] ] &|-->& D:(P|P'(c1) v1 (*) []|F)[ []| v2 c2| [] ]
% D:(P|c1 v1(*) []|F)[P'|c2 v2| [] ]  &|-->& D[P|c1(*)P'(c2) (v1, v2)| F]

and symmetrical rules for evaluation along the second branch.
%subcode{opsem} include main
% D:(P|v1 c1 (*) []|F)[P'| c2 v2| [] ] &|-->& D:(P,[] (*) P'(c2) v2,F)[ []| v1 c1| [] ]
% D:(P|[] (*) c2 v2|F)[P'|c1 v1| [] ] &|-->& D[P |P'(c1) (*) c2 (v1, v2)| F]

The later two rules will be relevant only for reverse execution.

\end{itemize}

%%%%%%%%%%%%%%%%%
\subsection{Rules for {{eta}} and {{eps}} }

The operation {{eps}} reverses the direction of a particle by
reversing the world.

Note that we deviate from the categorical definition of {{eta}} and
{{eps}} slightly in that they swap the order of {{-b}} and {{b}} in
choice of {{eta}}. This however does not affect us, because we deal
with a symmetric category.

\begin{itemize}
\item Grammar
%subcode{bnf} include main
% Values, v = () | (v, v) | L v | R v | -v
% Isomorphisms, iso &=& ... | eta | eps
% Combinators, c &=& iso | c (;) c | c(+)c | c (*) c

\item
Type judgement.
%subcode{opsem} include main
% eta &: 0 <-> (-b) + b :& eps

%subcode{proof} include main
%@ |- v : b
%@@ |- -v : -b

\item
Operational Semantics.
%subcode{opsem} include main
% D[P| (R v) eps| F]      &|-->&  D{dagger}[F | eps (L (-v))| P]
% D[P| (L (-v)) eps| F]      &|-->&  D{dagger}[F | eps (R v)| P]

Note: there is NO reduction rule for {{eta}}.

\item
The adjoint of a parallel context is defined to be:
%subcode{opsem} include main
% []{dagger} '= []
% (D:(P, [](+)c, F)){dagger} '= D{dagger}:(F, [](+)c{dagger}, P)
% (D:(P, c(+)[], F)){dagger} '= D{dagger}:(F, c{dagger}(+)[], P)
% (D:(P, [](*)c v, F)){dagger} '= D{dagger}:(F, [](*)v c, P)
% (D:(P, [](*)v c, F)){dagger} '= D{dagger}:(F, [](*)c v, P)
% (D:(P, c v(*)[], F)){dagger} '= D{dagger}:(F, v c(*)[], P)
% (D:(P, v c(*)[], F)){dagger} '= D{dagger}:(F, c v(*)[], P)

\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Diagrams}

{{eta}}

\begin{center}
  \includegraphics{diagrams/eta.pdf}
\end{center}

Note that the connective is a {{+}}, hence only one of the branches
may be inhabited at any time. Thus the action of {{eta}} is to
transfer a backward flowing value on one wire to a forward flowing
value on the other wire.

{{eps}}

\begin{center}
  \includegraphics{diagrams/eps.pdf}
\end{center}

Coherence condition

\begin{center}
  \includegraphics{diagrams/coherence.pdf}
\end{center}

Function

\begin{center}
  \includegraphics{diagrams/function.pdf}
\end{center}

Let us use the shorthand {{b1 -o b2 = -b1 + b2}}

Function application

\begin{center}
  \includegraphics{diagrams/apply1.pdf}
\end{center}

\begin{center}
  \includegraphics{diagrams/apply2.pdf}
\end{center}

Function composition

\begin{center}
  \includegraphics{diagrams/compose1.pdf}
\end{center}

\begin{center}
  \includegraphics{diagrams/compose.pdf}
\end{center}

This is also equivalent to sequencing both the computation blocks.

\begin{center}
  \includegraphics{diagrams/compose2.pdf}
\end{center}

Delimited continuation

\begin{center}
  \includegraphics{diagrams/delimc.pdf}
\end{center}

Trace

%subcode{proof} include main
%@ c : b2 + b1 <-> b2 + b3
%@@ trace c : b1 <-> b3

\begin{center}
  \includegraphics{diagrams/trace.pdf}
\end{center}

Double Negation

{{b <-> -(-b)}}

\begin{center}
  \includegraphics{diagrams/double_neg.pdf}
\end{center}

Negation distributes over {{+}}.

{{-(b1 + b2) <-> (b1) + (-b2)}}

\begin{center}
  \includegraphics{diagrams/dist_neg_plus.pdf}
\end{center}

{{eps_{fst} }}

{{(-b1)*b2 + b1*b2 <-> 0}}

\begin{center}
  \includegraphics{diagrams/eps_fst.pdf}
\end{center}

Lifting negation out of {{*}}.

{{(-b1) * b2 <-> -(b1 * b2) <-> b1 * (-b2)}}

\begin{center}
  \includegraphics{diagrams/mult_neg.pdf}
\end{center}

The following isomoprhism can be constructed similarly

{{b1 * b2 <-> (-b1)*(-b2)}}

Lifting a operation of postive types to negated types:

Given {{c : b1 <-> b2}}

\begin{center}
  \includegraphics{diagrams/neg_lift.pdf}
\end{center}

\paragraph*{Observability.}
Execution of program is defined by {{c : b1 <-> b2}} when evaluated on
input {{v1 : b1}} gives us a value {{v2 : b2}} on
termination. Execution is well defined only if {{b1}} and {{b2}} are
entirely positive types. Consider the program that

\begin{center}
  \includegraphics{diagrams/shuffle.pdf}
\end{center}

We define observables to be only positive types. The ouputs of
programs that ouput mixed positive and negative types are not
observable.  Also, programs that input mixed positive and negatives
types are not executable.

\subsection{To think about}

\begin{itemize}

\item If we built an effect over {{langRevEE}}, say {{create}} and
  {{erase}}, are effects structured by an arrow or a monad now?

\item Which operations can be lifted to work on negative types?

\item Can the operational semantics for {{langRevEE}} be an
  interpreter that is implemented in {{langRevT}} (similar to how the
  the tree traversal interpreter was implemented). This would imply
  the existence of a more powerful construction than Int, wherein the
  products would also be preserved. This is possibly worth a paper in
  itself.

\item These functions aren't really values. There is no value one can
  produce that denotes a function. These functions are the ability to
  transform a value - the possibility of transforming a value.  In the
  product encoding of environments, there is no value one can assign
  to a variable such that it denotes a function.

Actually this is possible. Consider two functions {{f : b1 <-> b2}}
and {{g : b1 <-> b2}}. A value of type {{bool}} is sufficient to
discriminate them. Hence the {{boo}} is the first class representation
of the functions and can be thought of as the address of the function.

\begin{center}
  \includegraphics{diagrams/dispatch.pdf}
\end{center}

\item It is not fair to say that negative types flow backwards. The
  following circuits are valid in {{langRevEE}}. It is however proper
  to say that for any type {{b}} that flows in a direction, the type
  {{-b}} flows in the reverse direction.

\begin{center}
  \includegraphics{diagrams/neg_circuit1.pdf}
\end{center}

\begin{center}
  \includegraphics{diagrams/neg_circuit2.pdf}
\end{center}

\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Multiplicative Duality in {{langRev}} }

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Related Work}
\label{sec:related}

Filinski proposes that continuations are a \emph{declarative} concept. He,
furthermore, introduces a symmetric extension of the $\lambda$-calculus in
which values and continuations are treated as opposites. This is essentially
what we are proposing with one fundamental difference: our underlying
language is not the $\lambda$-calculus but a language of pure isomorphisms in
which information is preserved. This shift of perspective enables us to
distill and generalize the duality of values and continuations: in
particular, in the conventional $\lambda$-calculus setting values and
continuations can be erased and duplicated which makes it difficult to
maintain the correspondence between a value and its negative counterpart.

\paragraph*{Continuations.} The idea of using negative types to model
information flowing backwards, demand for values, continuations, etc. goes
back to at Filinski's thesis. We recall these connections below but we first
note that all these systems are complicated because in all these systems
information can be ignored, destroyed, or duplicated. Clearly the possibility
of erasure of information would mean that our credit card transaction is
incorrect. In our work, information is maintained and hence we have a
guarantee that, in a closed program, the debt must be accounted and paid for.

\paragraph*{Filinski~\cite{Filinski:1989:DCI:648332.755574}.}
In his Masters thesis, Filinski proposes that continuations are a
\emph{declarative} concept. He, furthermore, introduces a symmetric extension
of the $\lambda$-calculus in which values and continuations are treated as
opposites. This is essentially what we are proposing with one fundamental
difference: our underlying language is not the $\lambda$-calculus but a
language of pure isomorphisms in which information is preserved. This shift
of perspective enables us to distill and generalize the duality of values and
continuations: in particular, in the conventional $\lambda$-calculus setting
values and continuations can be erased and duplicated which makes it
difficult to maintain the correspondence between a value and its negative
counterpart. In contrast, in our setting, one can start from the empty type
$0$, introduce a positive value and its negative counterpart, and let each of
these flow in arbitrary ways. The entire framework guarantees that neither
the value nor its negative counterpart will be deleted or duplicated and
hence that, in any closed program, the ``debt'' corresponding to the negative
value is paid off exactly once. The forward and backward executions in our
framework correspond to call-by-value and call-by-name. This duality was
observed by Filinski and others following him but it is particularly clean in
our framework.

\paragraph*{Subtraction} Wadler the reloaded paper, does not consider the
subtraction type because its ``computational interpretation is not
familiar.'' Curien and Herbelin study duality in classical logic, show that
it exchanges call-by-value and call-by-name. They extend classical natural
deduction with subtraction but give it no computational meaning. Crolard (in
the formulae-as-types interpretation of subtractive logic) address the
computational interpretation of substraction. He explains the type $A-B$ as
the of \emph{coroutines} with a local environment of type $A$ and a
continuation of type $B$. The description is complicated by what is
essentially the desire to enforce linearity constraints so that coroutines
cannot access the local environment of other coroutines. Must cite Selinger
control categories in this context of duality but I am not sure what to say:
it assumes cartesian closed categories for one thing and not symmetric
monoidal ones. Ariola, Herbelin, and Sabry also use subtractive types to
explain delimited continuations.

\paragraph*{Linear Logic} In accounts that are linear, the value and
continuation that comprise the substractive type need to be constrained to
``stay together.'' This can be achieved by various restrictions. In this work
we have no such constraints, the negative value can flow anywhere. The entire
system guarantees that any closed program would have to account for it. We
don't have to introduce special constraints to achieve that. Zeilberger in
the paper on polarity and the logic of delimited continuations uses polarized
logic: he shows that if positive and negative values are completely symmetric
except that answer types are positive, then the framework accommodates
delimited continuations. But he interprets negative values are control
operators, or as values defined by the shape of their continuations. We
simply interpret values of negative type as values flowing in the ``other''
direction.

\paragraph*{Int Construction.}
For a traced monoidal category {{C}} the Int construction produces a
Compact Closed Category called Int {{C}} \cite{joyal1996traced}.
Further we know that the target of the Int construction is isomorphic
to the target of \G construction of Abramsky \cite{Abramsky96:0} from
Haghverdi. However, note that the {{langRevEE}} is not the same as the
image of the Int construction on {{langRevT}}, since the the later
lacks a multiplicative tensor that distrbutes over the additive tensor
in Int {{langRevT}}.

\paragraph*{Recursion.} In our previous work we introduce recursive types and
trace operators. This is dangerous here because infinite loops allow us to
prolong paying the debt for as long as we want.

\paragraph*{GoI machines}
We can now encode the GoI machine of Mackie \cite{Mackie2011,DBLP:conf/popl/Mackie95}.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Conclusion}

\acks This project was partially funded by Indiana University's Office
of the Vice President for Research and the Office of the Vice Provost
for Research through its Faculty Research Support Program.  We also
acknowledge support from Indiana University's Institute for Advanced
Study.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{small}
\bibliographystyle{abbrvnat}
\bibliography{cites}
\end{small}

\end{document}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


\subsection{Analysis of spectral series containing more components}

Generally, the standard approach used in optical spectroscopic studies of NA
for analysis of a system with more components is based on a variation of some
parameter which influences the ratio between components and observation of the
impact of the change on the spectra.
For example, the concentration of ions or pH of the buffer can be modified in
titration experiments, and their influence on the preferred conformation or
complex formation can be observed
\parencite{Klener2015}.
Alternatively, increased temperature causes a structural transition of a folded
into an unfolded state
\parencite{Klener2021}.

Absorbance at one wavelength (260\,nm as a rule for UV absorption of NA) is
usually used as the monitored parameter.
Temperature-dependent measurements then model the temperature profile of the
absorbance by sigmoidal curve (typically derived from the Van't Hoff equation)
with linear asymptotes to take into account the temperature effects outside
the region of the temperature transition
\parencite{%
	Owczarzy1997,%
	Owczarzy2005,%
	Mergny2009%
}.

Changes in RS are richer and influence the intensity and positions of numerous
Raman bands.
A similar approach can be applied to individual spectral parameters of Raman
bands
\parencite{%
	Duguid1996,%
	Mukerji1996,%
	Mercier1999,%
	Baumruk2001,%
	Movileanu2002a,%
	Knee2008%
},
but the results are influenced by uncertainties in the subtraction of the
background signal, the effects of overlapping bands, and other experimental
errors.
It means that each individual spectral parameter gives different results making
it difficult to obtain a general picture of the underlying process.

Another alternative is a plot of differential spectra for spectral changes
during subsequent parameter steps
\parencite{%
	Duguid1996,%
	Baumruk2001,%
	Chan1997,%
	Movileanu1999,%
	Movileanu2002%
}.
They provide an excellent overview of thermally induced changes in individual
Raman bands but they do not determine the underlying chemical process's
parameters nor separatef different simultaneous processes.

The advantages of both of the above methods can be provided by a multivariate
analysis of a series of Raman spectra.
One suitable multivariate analysis method is
\emph{Principal component analysis} (PCA,
\cite{%
	Wold1987,%
	Malinowski2002%
}),
which reduces the measured spectra to several spectral profiles (loadings) and
scores indicating each profile's portion in the measured spectra.
The scores can then be fitted by a function based on an underlying chemical
model, and for example, thermodynamic parameters for structural transitions
can be estimated in temperature-dependent measurement
\parencite{Nemecek2013}.

PCA converts sets of experimental spectra $Y_i(\nu)$
into novel sets of mutually independent spectral profiles (loadings)
$U_j(\nu)$ and scores $P_{ij}$ representing their portions in the original
spectra
\begin{equation*}
	Y_i(\nu) = \sum_{j=1}^M P_{ij}U_j(\nu),
\end{equation*}
where $\nu$ is the wavenumber, $i \in \{1,\dots,N\}$ enumerates spectra from
the original spectral series of size $N$ and $M$ is the estimated number of
significant components.

Underlying chemical model for relationships between concentrations of the
chemical components $c_k(t_i)$ can be fitted to the loading $P_{ij}$
\begin{equation*}
	P_{ij}^\text{model} = \sum_{k=1}^{M_\text{c}} c_k(t_i) Q_{ki}(t_i)
\end{equation*}
where $t_i$ is the parameter value for spectrum number $i$ (for example
temperature, concentration of ions or pH),
$c_k(t_i)$ is concentration of chemical component $k$, which is dependent on
the parameter $t_i$,
$k$ enumerates on the number of chemical components $M_\text{c}$ and
$Q_{ki}(t_i)$ is polynomial in parameter $t_i$
\begin{equation*}
	Q_{ki}(t_i) = \sum_{l_k=0}^{L_k} a_{k,l_k} t_i^{l_k},
\end{equation*}
where $l$ enumerates on the degree of polynomial $L_k$ for the chemical
component $k$.
The underlying chemical model $c_k(t_i)$ explains the spectral changes
completely only when the polynomial $Q_{ki}(t_i)$ is of degree
$L_k = 0$, i.e. $Q_{ki}(t_i) = a_k$.
Higher degrees of the polynomial enhances the chemical model so that it can
better fit also other processes which are not sufficiently reflected in the
chemical model; for example,
\textcite{Klener2021}
applied polynomials of the first degree to accommodate for temperature effects
on folded/unfolded components even outside of the region of temperature
transition between the folded and unfolded state.

The relationships between $c_k(t_i)$ concentrations of chemical components from
the chemical model are usually not linear in the internal parameters $b_{k,m}$
of the model because the chemical model is usually dependent on equilibrium
constants $K$ in a nonlinear manner.
Moreover, Van't Hoff equation is usually used in the case of
temperature-dependent measurement, which introduces exponential dependency of
the equilibrium constants on entropy and enthalpy.

The least-squares regression with the internal model parameters $a_{k,l_k}$ and
$b_{k,m}$ minimizes the sum of squares
\begin{equation}
	S(a_{k,l_k},b_{k,m}) = \sum_{i=1}^N{\sum_{j=1}^M{
		\left[P_{ij} - P_{ij}^\text{model}(a_{k,l_k},b_{k,m})\right]^2
	}},
	\label{\eqnlabel{two_comp:sos}}
\end{equation}
which is, as discussed above, linear in polynomial parameters $a_{k,l_k}$ and
nonlinear in parameters $b_{k,m}$.
Nonlinear minimization is usually much more expensive because it utilizes
iterative methods of searching for the minimum.
They are also susceptible to finding only local minima.
On the other hand, linear least squares regression is “just” solution of a set
of normal equations
\parencite[p.~671]{NumericalRecipes}.
It means that the nonlinear iterative minimization algorithm can be applied
to $b_{k,m}$ values, the $a_{k,l_k}$ values are estimated by linear least
squares for the given $c_k(t_i)$ which are determined by the values of
$b_{k,m}$.


%!TEX root = ceres.tex
\chapter{Introduction}
\label{sec:introduction}
Ceres Solver\footnote{For brevity, in the rest of this document we will just use the term Ceres.} is a non-linear least squares solver developed at Google. It is designed to solve small and large sparse problems accurately and efficiently~\footnote{For a gentle but brief introduction to non-liner least squares problems, please start by reading the~\hyperref[chapter:tutorial]{Tutorial}}. Amongst its various features is a simple but expressive API with support for automatic differentiation, robust norms, local parameterizations, automatic gradient checking, multithreading and automatic problem structure detection.

The key computational cost when solving a non-linear least squares problem is the solution of a linear least squares problem in each iteration. To this end Ceres supports a number of different linear solvers suited for different needs. This includes dense QR factorization (using \eigen) for small scale problems, sparse Cholesky factorization (using \cholmod) for general sparse problems and specialized Schur complement based solvers for problems that arise in multi-view geometry~\cite{hartley-zisserman-book-2004}.

Ceres has been used for solving a variety of problems in computer vision and machine learning at Google with sizes that range from a tens of variables and objective functions with a few hundred terms to problems with millions of variables and objective functions with tens of millions of terms.

\section{What's in a name?}
While there is some debate as to who invented of the method of Least Squares~\cite{stigler1981gauss}. There is no debate that it was Carl Friedrich Gauss's prediction of the orbit of the newly discovered asteroid Ceres based on just 41 days of observations that brought it to the attention of the world~\cite{tennenbaum-director}. We named our solver after Ceres to celebrate this seminal event in the history of astronomy, statistics and optimization.

\section{Contributing to Ceres Solver}
We welcome contributions to Ceres, whether they are new features, bug fixes or tests. If you have ideas on how you would like to contribute to Ceres, please join the Ceres mailing list (\texttt{ceres-solver@googlegroups.com}) or if you are looking for ideas, please let us know about your interest and skills and we will be happy to make a suggestion or three.

We follow Google's C++ Style Guide~\footnote{\url{http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml}}.

\section{Citing Ceres Solver}
If you use Ceres for an academic publication, please cite this manual. e.g.,
\begin{verbatim}
@manual{ceres-manual,
	Author = {Sameer Agarwal and Keir Mierle},
	Title = {Ceres Solver: Tutorial \& Reference},
	Organization = {Google Inc.}
}
\end{verbatim}

\section{Acknowledgements}
A number of people have helped with the development and open sourcing of Ceres.

Fredrik Schaffalitzky when he was at Google started the development of Ceres, and even though much has changed since then, many of the ideas from his original design are still present in the current code.

Amongst Ceres' users at Google two deserve special mention: William Rucklidge and James Roseborough. William was the first user of Ceres. He bravely took on the task of porting production code to an as-yet unproven optimization library, reporting bugs and helping fix them along the way. James is perhaps the most sophisticated user of Ceres at Google. He has reported and fixed bugs and helped evolve the API for the better.

Nathan Wiegand contributed the MacOS port.
\clearpage

\section{License}
Ceres Solver is licensed under the New BSD license, whose terms are as follows.

\begin{quotation}

\noindent
Copyright (c) 2010, 2011, 2012, Google Inc. All rights reserved.

\noindent
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
\begin{enumerate}
\item Redistributions of source code must retain the above copyright notice,
      this list of conditions and the following disclaimer.
\item Redistributions in binary form must reproduce the above copyright notice,
      this list of conditions and the following disclaimer in the documentation
      and/or other materials provided with the distribution.
\item Neither the name of Google Inc.,  nor the names of its contributors may
      be used to endorse or promote products derived from this software without
      specific prior written permission.
\end{enumerate}

\noindent
This software is provided by the copyright holders and contributors "AS IS" and
any express or implied warranties, including, but not limited to, the implied
warranties of merchantability and fitness for a particular purpose are
disclaimed. In no event shall Google Inc. be liable for any direct, indirect,
incidental, special, exemplary, or consequential damages (including, but not
limited to, procurement of substitute goods or services; loss of use, data, or
profits; or business interruption) however caused and on any theory of
liability, whether in contract, strict liability, or tort (including negligence
or otherwise) arising in any way out of the use of this software, even if
advised of the possibility of such damage.
\end{quotation}