% Allow relative paths in included subfiles that are compiled separately
% See https://tex.stackexchange.com/questions/153312/

\providecommand{\main}{..}
\documentclass[\main/thesis.tex]{subfiles}
\externaldocument{}

% \iffalse
% - Capturing and playing sound, digitally
% - Representation (single frame vs multi(spectrum))
% - Creating sound
%     - Sound can be created functionally
%     - sound can be created piece by piece
% - a quick history/summary of computer music technology (the parts of it that are relevant to our project)
%     - Define vsts, synth parameters, filters, eqs since some they're involved in some of the previous works.
% - Past work involving heuristic search and digital synths
% - Past work involving generative neural nets
% - Our work and how it's different or extends past work
%     - How it can be replicated
% \fi

% todos:
% properly use amplitude and magnitude and power
% haven't described timbre
% make reconstruction wave include multiple waveforms and how they go missing if sampling rate too slow
% haven't described nyquist frequency

\begin{document}

\chapter{Background and Related Work}
\label{section:background}
This chapter aims to provide a background for the subsequent chapters by providing a quick overview of four important topics:\\
\begin{enumerate}[label=(\roman*)]
\item Digital sound, its features, and concepts that have been fundamental to our work.
\item Common digital synthesis techniques.
\item The applications of artificial neural networks (ANNs) for feature extraction and sound production. Although similar results can be yielded from either approach, we distinguish ANN based techniques from tradition digital signal processing (DSP).
\item Related works and their relative similarities and distinctions.
\end{enumerate}
\section{Digital Audio: Sound from Numbers}
\label{sec:digital_audio}
Sound is the result of a series of physical events. Most of what we hear is the product of physical disturbances, causing vibrations in our mutually shared, immersive mediums. Sound waves are vibrations traveling through air as part of an expanding, spherical wave front, exponentially losing intensity as they travel away from the source~\cite{cook1999chap4}.
\\

% [graph describing wave amplitude, phase and frequency here]
A sound wave can be viewed as the result of a function which governs amplitude through time, where time and amplitude exist in continuous dimensions. Waves can be approximated via a series of samples, associating time steps to a discrete range of amplitude values.
Given a wave generation method, computers can make sound by sending a series of discrete values to a digital to analogue converter(DAC), which in turn can
create vibrations within a speaker.  \textit{Digital synthesis} of audio is the process of creating these discrete values.
\\

\subsection{Sampling Rates and Quality of Digital Audio}
\label{sec_sampling_rates}
In 1963, Mathews wrote on the potential and utility of computers as digital instruments~\cite{mathews1963digital}. He presented a snapshot of digital audio technology of his time and made predictions on what would be possible in the future~\cite{mathews1963digital}. This work by Mathews makes the robust foundations of digital signal processing apparent. Many of the techniques described by Mathews have not only remained popular and relatively unchanged, but also benefited from the increase of computational power throughout the decades~\cite{mack2011fifty,smith1991viewpoints}. For instance, Mathews described a general method for computers to capture and internally represent audio: by discretely sampling continuous pressure waves of sound and recreating the sound from the recorded numbers.

Sound can take on the physical characteristics of a waveform~\cite{cook1999chap4}. Imagine the curve shown in Figure~\ref{fig_sampling_rate} is representative of a sound wave we would like to digitally capture. As the sound travels through a microphone, sensors record samples of information about it at fixed intervals. This means that the original, analogue waveform is now recorded as a discrete, digital signal. Each recorded sample would represent the amplitude of the wave at a time-step. The more packets of information we get, the better our digital recreation of the original sound.

In this context, \textit{sampling rate}, is an important feature of digital sound, referring to the number of samples per second of audio (measured in hertz, or Hz). Sampling rate is not the only important factor when recording audio as it is important to record with not just speed, but also precision. Assuming perfect sensors, precision is the range of possible values we can assign to each sample. It is determined by bit depth: the number of bits we have to represent the values of each sample.  Today, standard quality audio often refers to sampling rates of 44.1 kHz and 48 kHz and bit depth of 16 (that is, $2^{16}$ discrete values), while \enquote{high quality} audio indicates an increase in bit rate or bit depth~\cite{reiss2016meta}. Although subject to diminishing returns, high quality audio (e.g., 96 kHz/24-bit) may be preferable to most musicians and audio-engineers. In a meta-analysis of digital sound perception, Reiss found a small but statistically significant portion of people are able to discriminate the effect of standard and high quality audio with no prior training, and a dramatically higher detection rate after extensive training~\cite{reiss2016meta}.

\begin{figure}[tbp]

\centering
\includegraphics[width=1\linewidth,angle =-90 ]{images/periodic_function_decimation.png}
\caption{Inadequate sampling rates can make reconstruction ambiguous. While reconstruction is possible in this case, consider the case when multiple signals with varying frequencies are overlapped, or the case when samples are further apart than 1 wave length.}
\label{fig_sampling_rate}
\end{figure}

\subsection{Loudness, Amplitudes and Envelopes}
\label{sec:adsr}
Loudness is a subjective description of a sound's intensity or energy levels. It varies based on the complexity of sounds, the frequencies present, and hearing ability of the listener~\cite{fletcher1933loudness,cook1999chap6}. It can only be measured relatively, by establishing a benchmark sound and surveying populations on the relative intensities~\cite{cook1999chap6}. Since loudness and intensity of sound correlate with the amplitude of digital waveforms (the values assigned to the samples), an imperfect but convenient alternative method for inferring the loudness of digital sounds is to compare relative amplitudes. A common function for inferring the loudness of digital signals is to apply the Root Mean Square (RMS) function to its samples~\cite{zwicker1977procedure}.

Sounds typically vary in intensity as they unfold. This change in intensity is often described by the \textit{envelope} of the sound, particularly in shorter samples. For digital sounds, Mitchell describes the envelope as either of the borders (since samples typically take the range of -1 to 1) that are created by graphing a signal and connecting the local absolute peak values~\cite{mitchell2009basicsynthChap6}. In electronic music production, the envelope is generally defined using 4 features: Attack, Decay, Sustain, and Release (ADSR). Attack describes how quickly the peak loudness is reached. Decay for how quickly the sound drops to sustain level. Sustain is the duration of sustaining intensity (for example, how long a finger is kept on a piano key). Release describes the speed of fading to silence (how fast the sound decays once the piano key is released). We will describe our method of approximating the envelope of sounds in Section~\ref{sec:fourier_transforms}.

Envelopes can be mathematically described and used to shape signals. A common approach in digital sound synthesis is to output all samples at a consistent amplitude and apply an envelope later down the synthesis chain. Digital and analog synthesizers often have built-in ADSR modules to shape the volume of the output and other parameters.

% [Graph of envelope shaping a signal]
% note: make sure you're using terms signal and waveform properly
\subsection{Frequency, Pitch and Spectrograms}
\textit{Frequency} is used to describe number of repetitions within a time-frame, or how frequently a cycle is repeated. As discussed before, frequency of an audio signal is often measured in unit of \textit{hertz} (cycles per second). Most sounds, particularly those from non-virtual sources, are a combination of multiple different pressure waves with different frequencies and amplitudes. \textit{Pitch}, is a perceptual property that is tied to the frequencies present in a sound. How we perceive and describe the pitch of a sound (e.g., high-pitched vs low-pitched) is heavily dependent on the characteristics (frequency, amplitude, duration, etc) of the waveforms it contains. Some sounds, such as piano keys or pure tones have a discernible pitch. Others, such as \enquote{pink noise} or the sound of rain, do not. Yet another factor to consider is the hearing ability of the subject, which varies between people based on factors such as age, environment, and musical training~\cite{reiss2016meta,alain2007age,newman2012grm7}.

% We often do not have access to the time-variant systems which create sounds. If we have access to a recording of their outputs (i.e digital sound), we can make approximations about their characteristics.
Spectrograms are graphs used to depict the duration and amplitude of frequencies present in a sound. To create spectrograms, sound must be decomposed into a set of simpler functions. A common method for the breakdown of complex, time-variant functions is the Fourier transformation and its many variations. One such method is the discrete Fourier transformation (DFT) and the inverse DFT. DFT and inverse DFT can convert digital sound from its time domain representation (sequence of samples) to its frequency domain representation (sets of frequency ranges and their amplitude) and vice versa. We share some examples along with our methodology of creating spectrograms in Section~\ref{sec:fourier_transforms}.\\\\

% [spectrogram figures]

% https://en.wikipedia.org/wiki/Frequency_domain#/media/File:Fourier_transform_time_and_frequency_domains_(small).gif

\section{Digital Audio Synthesis}
\label{sec_digital_synthesis}
The phenomena of sound at intensities we commonly encounter can be described as a product of a \textit{linear system} of functions~\cite{cook1999chap4}. A linear system is a system where the transformation of overlapping inputs is equal to the sum of the separately transformed inputs~\cite{lyons2004understandingChap1,cook1999chap4}. In a linear system $\mathcal{S}$ with valid inputs and outputs $x(i)$ and $y(i)$, if we have:

\begin{equation}
 \mathcal{S}(x(i_1)) \xrightarrow{generates} y(i_1)
\end{equation}
\begin{center}
    and
\end{center}
\begin{equation}
\mathcal{S}(x(i_2)) \xrightarrow{generates}y(i_2)
\end{equation}

The output of the system given both inputs is the sum of the individual outputs, or:
\begin{equation}
 \mathcal{S}(x(i_1)+x(i_2)) \xrightarrow{generates} y(i_1)+y(i_2)
\end{equation}
\\
This concept has important implications digital audio creation and analysis. Simple tones can be combined to create complex sounds, and complex sounds can be broken down for easier analysis~\cite{lyons2004understandingChap1}. It also allows experiments with simple sine waves to remain relevant in complex sound domains~\cite{cook1999chap4}.

% [graph of addition of two sine waves making a complex sine wave ]
% \\

Various sound synthesis techniques have been developed by treating sound as a sequence of values. Linear systems are commonly used in creation of musical tones, while non-linear systems are used for introduction of distortion and noise where needed. In their taxonomy of digital synthesis techniques, Smith defines four families of algorithms: algorithms that process and modulate existing sounds (e.g., granular synthesis, wavelets), spectral models that aim to create a particular spectrum of sound (e.g., additive, subtractive), physical models which emulate the physics of real instruments, and abstract models (e.g., wave shaping, Karplus-Strong), often used for adding harmonics or distortion to simple sound signals~\cite{smith1991viewpoints}.

Synthesizers are engines of synthesis that make use of one or more of these techniques for sound generation. Selection of the appropriate synthesis method depends not only on the expectations for the end product, but also the features of the synthesizer itself. Whether in goal oriented tasks such as text-to-speech or in creative endeavors such as ambient-noise generation, it is often desirable to work with systems that are quick, adaptable and tractable. For example, one might desire a text-to-speech system where slight changes to input parameters can introduces slight changes to the speech patterns, utterances, voices, etc. This ability to quickly modify and audition sounds becomes a necessity when the synthesizer is being used as a creative instrument in of itself, rather than an emulator for existing instruments and sounds.

Often used methods of digital sound generation are \enquote{additive} and \enquote{subtractive} synthesis, umbrella terms for some of the most simple and common methods of digital synthesis~\cite{mitchell2009basicsynthChap1}.
In additive synthesis, sounds are built as a sum of signals, where signals are outputs of oscillators (periodic wave generators).  In subtractive synthesis, segments of a complex signal are removed until a desired sound is reached. A chain of one or more \textit{digital filters}, which can subtract or reduce frequency ranges, are often used in subtractive synthesis. Digital \textit{low-pass filters} lower the amplitude of signals with frequencies higher than a given \textit{cutoff}, while \textit{high-pass} filters remove lower than threshold frequencies. It is not uncommon for percussive sounds to have noisy, chaotic high frequency content during their short attack period, followed by harmonic low/medium frequencies~\cite{lakatos2000common}.

% \subsection{Analog Synthesizer}
% Talk about analog synthesis briefly, so the word synthesizer feels less abstract...
\subsection{Virtual Synthesizers}
Nearly 5 decades ago, Mathews claimed that any sound can be recreated via a computer by high frequency sampling of pressure waves~\cite{mathews1963digital}. He noted that since \enquote{a very high sampling rate is required...if this process is to be useful musically, programs for generating samples from the parameters of notes must be written}~\cite{mathews1963digital}. The methods of synthesis discussed here are a major component of such programs. With the exception of physical synthesis, modern chips are more than capable of simultaneously running many instances of these algorithms. To further assist with their musical utility, the majority of digital synthesis systems work in tandem with programs such as Musical Instrument Digital Interface (MIDI), which can modulate the parameters of these synthesis methods by modulating information pertaining to ADSR and other note characteristics, often in real time~\cite{moog1986midi}.

 The rise of Digital Audio Workstations (DAWs)~\cite{leider2004digital} and Virtual Studio Technology (VST) plug-ins~\cite{tanev2013virtual} have rapidly transformed the sonic and material landscape of music production in the recent years. Coupled with this rise in popularity is a vast array of commercial products and services which cater to the need of amateur and professional music producers for unique sounds, often by provision of audio samples; one-shot drum samples, long sustained notes (referred to as pads or textures), and loops (percussive or melodic) are common deliverables. Two notable examples of these commercial services are \textit{loopmasters}\footnote{loopmasters.com} and \textit{splice.com}\footnote{splice.com}. VST plug-ins can emulate analogue synthesizers and effects,  however,  due to their (often) complex interface, some producers may find VST plugins daunting to work with from scratch. In many cases, VST plug-in vendors or unaffiliated enthusiasts sell additional presets for these plugins, targeted towards producers who do not have the time or interest in creating their own. The flexibility of the VST technology allows producers to modify these presets until their desired sound is reached.

\section{Neural Networks And Sound}
\label{bg:NN}
In Section~\ref{sec:digital_audio}, we defined digital synthesis as the \enquote{process of generating discrete values which approximate sound waves}. We also established that manual generation of these values at high sampling rates is near impossible; a problem which has motivated a wide variety of synthesis techniques which aim to create signals within a linear (or mostly linear) system. The recent exponential increase in computing power has been coupled with a wide range of research in probabilistic sound generation, mainly via generative neural networks.
% deterministically, if the input parameters to the system do not change, the output of the system will remain the same \footnote{talk about noise generation methods and seeding}.

Artificial Neural networks (ANNs) map inputs to outputs via a large network of parameters and activation functions. Given the right network shape and parameter weights, they can approximate a large set of functions~\cite{cybenko1989approximation,cardaliaguet1992approximation}. ANNs are often deployed when we do not have access to the system of functions which guide a process, but a mapped set of inputs and the corresponding outputs are available. Given this set, the parameters of a neural network can be tuned for approximating the effect of the system on any valid input. The architecture of the neural network (e.g., number of layers, connections, activation functions) is often selected via trial and error ~\cite{bergstra2012random,bergstra2011algorithms,ba2013adaptive}. By definition, these approximations will never be more accurate than the system that is being approximated.

Since their emergence in the 1950's, research on ANNs has gone through several eras of stunted growth~\cite{basheer2000artificial,anderson1988neurocomputing}.  In the last decade, the increase in the affordability of high performance graphic cards has been coupled with a major resurgence of interest for ANNs and the emergence of a number of domain specific variations of the traditional ANN architectures (see Section~\ref{related}).

Generative neural networks (GNNs) are utilized for the completion of sequences of values; often by taking an incomplete sequence as input and outputting the most likely value for the next step. The WaveNet architecture introduced in 2016 is considered a seminal breakthrough in the usage ANNs for sound synthesis~\cite{oord2016wavenet} by surpassing state of the art speech synthesis techniques, which create outputs with the the combination of previously recorded audio snippets~\cite{schwarz2007corpus}. When trained on a large corpus of audio samples, GNNs such WaveNet can learn the \enquote{predictive distribution for each
audio sample conditioned on all previous ones}~\cite{oord2016wavenet}. Once this distribution is learned, it can be used to create sounds 1 sample at a time, a slow process, as Mathews predicted~\cite{mathews1963digital}. \\
% Parallel WaveGAN has only 1.44 M parameters and can generate 24 kHz speech waveform 28.68 times faster than real-time on a single GPU environment. Perceptual listening test results verify that our proposed method achieves 4.16 mean opinion score within a Transformer-based text-to-speech framework, which is comparative to the best distillation-based Parallel WaveNet system.

% \section{Goal Oriented Novel Sound Generation}

% \subsection{Tool Selection}
% We define \enquote{goal oriented novel sound generation} as any work that seeks to implement a system that is capable of generating novel sounds with a desired characteristic. Based on our review of relevant works, we believe that \enquote{goal oriented audio generation} necessitates two essential components: A tool-set for the analysis of sound and a tool-set for creation of sound. As a result, we base our work around learning of the distinguishing features of various sound groups (i.e different types of drums) and using the learned features for generation of sound. In Section~\ref{sec_methodology} we introduced these components as the virtual ear and virtual synthesizer.

%  Thus far we have discussed various techniques at our disposal for the implementation of a virtual ear and synthesizers. In the upcoming Sections, we will discuss the implementations and the subsequent results. Here, we will review a variety of works which fall under our definition of \enquote{goal oriented novel sound generation}. Particularly, we are interested in a discussion of goals, chosen methods for the feature extraction, and chosen methods of sound synthesis.

\subsection{Related Works}
\label{related}

\begin{center}
\begin{table}[]
% \resizebox{\linewidth}{!}{
\begin{tabular}{||c c c c||}
\hline
work & feature extraction & synthesis & specilization  \\
	\hline
Oord et al.~\cite{oord2016wavenet} & CNN & CNN &Speech \\
	\hline
Yamamoto et a.l~\cite{yamamoto2020parallel} & GAN & GAN&Speech  \\
	\hline
Aouameur et al.~\cite{aouameur2019neural} & Latent layer& Decoding of Latent Layers & Percussion  \\
	\hline
Ramires et al.~\cite{ramires2020neural} & Latent layer & FeedForward Network & Percussion  \\
	\hline
Yee-King et al.~\cite{yee2018automatic} & LSTM on Paremters & DSP & Synth Pads  \\
	\hline
\end{tabular}
%}
\caption{Quick reference for related works}
\end{table}
\end{center}

ANN or DSP approaches can be taken towards the implementation of a virtual ear and a virtual synthesizer. The recent development of ANN frameworks has led to works which have utilized ANNs for both components~\cite{oord2016wavenet,yamamoto2020parallel,ramires2020neural}. Also common are works which have leveraged a mixture of both approaches, often by utilization of ANNs for the virtual ear and DSP methods for synthesis~\cite{aouameur2019neural,yee2018automatic}.

Many deep neural network models have been proposed and utilized for the purpose of signal generation in recent years. WaveGans and WaveNet have been subject to significant improvements and experiments since their proposal~\cite{nsynth2017,yamamoto2020parallel,oord2017parallel}. Specifically for the generation of percussive sounds, a recent work by Aoumaeur et al.~\cite{aouameur2019neural} utilizes variational AutoEncoders (VAE's) for generation of drum sound spectrograms, which are then converted to sound using a Multi-head CNN model~\cite{aouameur2019neural}. Another recent work by Ramires et al.~\cite{ramires2020neural} also uses neural networks for this purpose, where a feedforward neural network capable of creating sounds is guided by a small number of parameters which represent the producer's desired characteristics for a drum sound.

Automatic programming of virtual synthesizers has also been a topic of interest. Genetic Algorithms have long been utilized for the generation of new sounds with various sound-engines~\cite{johnson1999exploring,dahlstedt2001creating,hornermachinetongues,macret2012automatic}. More recent work by Yee-King et al.~\cite{yee2018automatic} used Long Short-Term Memory (LSTM) models and genetic algorithms to find the exact parameters used to create a group of sounds. The sounds approximated were made by the same virtual synthesizer, not an external source; making the eventual replication certain even with random search. In addition, the work by Yee-King et al.~\cite{yee2018automatic} is generally more focused on pads and textures rather than drums, and feature matching appears to not be concerned with the envelope of the sounds but rather the frequency content within arbitrary time windows. Yet another recent work by Esling et al. used a large dataset of over 10,000 presets for a commercial VST synthesizer to learn a latent parameter space which can be sampled for creation of new programs for audio synthesizers~\cite{esling2019universal}. This bespoke latent space requires large amounts of synthesizer programs for the initial training, and cannot be used for other virtual synthesizers. In the work presented here, we take a different approach to automatic programming of synthesizers by aiming for rapid approximation of percussion sounds with no previous knowledge about the sonic capabilities of our virtual synthesizer and exploring the actual parameter space rather than its latent representation. Unlike previous related works, no prior examples of audio made by the synthesizer nor examples of manually generated programs are needed for our approach. Any synthesizer can be integrated into our system so long as \begin {enumerate*} [label=\itshape\alph*\upshape)]
  \item its parameters are known,
  \item the system can randomly modify its parameters, and
  \item The system can render and extract the sound output for virtual listening tests.
\end{enumerate*}
These requirements are not strict as VST synthesizers meet these expectations by design, giving our project a large scope of applicability.
\end{document}


\documentclass[]{spie}  %>>> use for US letter paper
%\documentclass[a4paper]{spie}  %>>> use this instead for A4 paper
%\documentclass[nocompress]{spie}  %>>> to avoid compression of citations

\renewcommand{\baselinestretch}{1.0} % Change to 1.65 for double spacing
\let\proof\relax
\let\endproof\relax
\usepackage{amsmath,amsfonts,amssymb,amsthm}
\usepackage{graphicx}
\usepackage[colorlinks=true, allcolors=blue]{hyperref}
\usepackage{chngcntr}
\usepackage{hyperref}
\usepackage{courier}

\counterwithin{figure}{section}
\counterwithin{table}{section}

\DeclareMathAlphabet{\pazocal}{OMS}{zplm}{m}{n}

\newtheorem{prop}{Proposition}
\theoremstyle{definition}
\newtheorem*{defn*}{Definition}
\newtheorem{defn}{Definition}

\newcommand{\ax}{\vec{x}}

\title{Python code description of the Feature Based Scheduler}

\author[a]{Elahesadat Naghib}

%\authorinfo{Further author information: (Send correspondence to E. N.)\\ E.N.: E-mail: enaghib@princeton.ed\\  R.J.V.: E-mail: rvdb@princeton.edu}

% Option to view page numbers
\pagestyle{plain}

\begin{document}
\maketitle

%\begin{abstract}

%Feature-based Scheduler offers a sequencing strategy for ground-based telescopes. This scheduler is designed in the framework of Markovian Decision Process (MDP), and consists of a sub-linear online controller, and an offline supervisory control-optimizer. Online control law is computed at the moment of decision for the next visit, and the supervisory optimizer trains the controller by simulation data. Choice of the Differential Evolution (DE) optimizer, and introducing a reduced state space of the telescope system, offer an efficient and parallelizable optimization algorithm. In this study, we applied the proposed scheduler to the problem of Large Synoptic Survey Telescope (LSST). Preliminary results for a simplified model of LSST is promising in terms of both optimality, and computational cost.

%
%\vspace{1cm}
%\end{abstract}
%
%\keywords{Telescope scheduler, Observation scheduling, Observing strategy, LSST, Decision making, Evolutionary Algorithm, Optimal control, Optimization}

\begin{center}
\textbf{Key terms and notations}\
\noindent\rule{\textwidth}{0.4pt}
\end{center}
\begin{tabular}{ l l  }
$t$& GMT time in Julian Date,\\ %$2459215.5 \leq t \leq 2462867.5$ i.e. from January 1, 2021, to January 1, 2031\\
$\tau_s(t)$& beginning of the night that $t$ lies in,\\
$\tau_e(t)$& end of the night that $t$ lies in,\\
$id(t)$& ID of the field that is visited at $t$, $id \in \{1,2,3,...,4206\},$\\
$\theta_{l}(i,t)$& time of the last visit of field $i$ before $\tau_s(t)$, $\theta_{l}(i,t) = \infty$ if field $i$ is not visited before $\tau_s(t)$,\\
$\theta_{l}^N(i,t)$& time of the last visit of field $i$ between $\tau_s(t)$ and $t$, $\theta_{l}^N(i,t) = \infty$ if field $i$ is not visited in this interval,\\
$n(i,t)$ & number of the visits of field $i$ before $\tau_s(t)$\\
$n^N(i,t)$ & number of the visits of field $i$ between $\tau_s(t)$ and $t$, $0 \leq n^N(i,t) \leq 3$\\
$SM_{i,j}$& slew time from field $i$ to field $j$, $SM \in \mathbb{R}^{4206 \times 4206}$ is a given slew matrix,\\
$alt(i,t)$ & altitude of the center of field $i$ at $t$, $-\frac{\pi}{2} \leq alt(i,t) \leq \frac{\pi}{2}$,\\
$ha(i,t)$ & hour angle of the center of field $i$ at $t$, $-12 \leq ha(i,t) \leq 12$\\
$\tau_{rise}(i,t)$ & rising time of field $i$ above the 1.4 airmass horizon at current night, $\tau_{rise}(i,t) = -\infty$ if $i$ never sets down,\\
$\tau_{set}(i,t)$ & setting time of field $i$ below the 1.4 airmass horizon at current night, $\tau_{set}(i,t) = \infty$ if $i$ never sets down,\\
$M_{\phi}(t)$ & percent of the Moon's surface illuminated at $t$,\\
$M_{sep}(i,t)$ & Moon's separation from field $i$ at $t$, $0 \leq M_{sep}(i,t) \leq \pi$,\\
$W_1,~W_2$ & given constant time window in which a revisit is valid, $0 < W_1 < W_2$\\
$time slots$\\
$visibility$\\
$brightness$\\
\end{tabular}\\
\noindent\rule{\textwidth}{0.4pt}\\

\section{FB scheduler code in Summary}\label{sec:intro}
Code repository on github: \href{https://github.com/elahesadatnaghib/LSSTschedulerV2} {FB Scheduler}

\textbf{Main files}:
\begin{itemize}
\item \textbf{CreatDB.py}:  creates the database, tables, data structure, and feeds the model parameters into the database.
\item \textbf{FieldDataGenerator.py}: evaluates  fields' predictable data such as altitude, at certain time intervals and writes them on the database.
\item \textbf{FBDE.py}: is where the heart of the scheduler is. it (1) reads the data in, stores the field data into field objects, (2) for each visit, loops over the field objects and (3) update the timing and the fields for the next visit decision.
\item \textbf{UpdateDB.py}: reads the out put of FBDE.py (the visit sequence), (1) evaluates the statistics and history dependent variable required for the next episode scheduling and (2) writes them into the database
\end{itemize}

\newpage
\section{FB scheduler code in details}
\vspace{1cm}

Class DataFeed\\
\indent connect to database \\
\indent read in ID, RA, Dec, Science label, $\theta_{l}(i,t)$, and $n(i,t)$ of all fields\\
\indent read in $alt(i,t)$, $ha(i,t)$, visibility, cloud coverage, and brightness of the fields for all time intervals\\
\indent read in model parameters: $\infty$, $\epsilon$, Exposure time, $W_1,~W_2$, maximum number of visit per night\\
\indent read in slew times from file\\
\indent create and initialize field(\textit{FiledState}) objects, one object for each field\\
\indent create episode(\textit{EpisodeStatus}) object, one object for one episode of scheduling (mostly a night)\\

\noindent Class Scheduler(DataFeed)\\
\indent scheduler\\
\indent \indent initialize episode\\
\indent \indent create output sequence structure\\
\indent \indent $while~ t <$ end of the episode\\
\indent \indent \indent $for$ all fields\\
\indent \indent \indent \indent update field feasibility\\
\indent \indent \indent \indent evaluate cost of feasible fields\\
\indent \indent \indent make the decision of next visit based on the costs\\
\indent \indent \indent simulate the visit \{evaluate the visit time, update the target field object\}\\
\indent \indent \indent record visit in a text file and in the output array\\
\indent \indent \indent update the episode \{update $t$, update current field, update current filter\}\\
\indent \indent \indent update all fields variable\{$alt(i,t)$, $ha(i,t)$, visibility, cloud coverage, and brightness, $SM_{i,current field}$\}\\
\indent \indent save the output array containing sequence of the visits for the episode\\

\noindent Class EpisodeStatus\\
\noindent \texttt{keeps track of the timing and other changing variables with time}\\
\indent initial variables: \{$\tau_s(t)$, $\tau_e(t)$, time intervals where the fields data are calculated at\}\\
\indent updatable variables: \{$t$, decision number, last visited field, current filter\}\\

\noindent Class FieldState\\
\noindent \texttt{keeps track of the state of each field}\\
\indent initial variables for the $i^{th}$ object (a field): \{ID, RA, Dec, Science label, $\theta_{l}(i,t)$, and $n(i,t)$\}\\
\indent data stored in the $i'th$ object (a field):\\
\indent \{$alt(i,t)$, $ha(i,t)$, visibility, cloud coverage, and brightness, for all time slots, and $SM_{i, all other fields}$\}\\
\indent updatable variables:\\
\indent \{$alt(i,t)$, $ha(i,t)$, visibility, cloud coverage, and brightness, for the current time, $SM_{i,current field}$\}\\
\indent updatable variables by calculation: \{time since last visit, time to become invisible, feasibility, cost\}

\newpage
\section{Run the scheduler}
\vspace{1cm}

\subsection{Required packages}
Code is developed in Python2.7.10, and the following packages are required to be installed:

\begin{itemize}
\item PyEphem
\item Numpy
\item SQLite3
\item JSON
\item Pandas
\item time
\item Matplotlib
\item ProgressBar
\end{itemize}

\subsection{Required data}
Labeled field information: "/NightDataInLIS/Constants/fieldID.lis", can be downloaded \href{https://www.dropbox.com/s/0dfuuffx9aoyfix/fieldID.lis?dl=0}{here}\\
Slew matrix: "/NightDataInLIS/Constants/slewMatrix.dat.lis", can be downloaded \href{https://www.dropbox.com/s/6gdyv4pofzb57vz/slewMatrix.dat?dl=0}{here}

\subsection{Quick start with FB scheduler code}

Scheduling of the LSST is a history dependent procedure, and the validity of the decisions in a certain night depends on the successful scheduling of all previous nights, evaluating the history dependent data (such as total number of visits), and storing them in the database.

\begin{enumerate}
\item \textbf{init\_setup.py} is a one-time procedure: creates a database in the main directory with field's data for 10 nights, starting from 2021/01/01, (takes around 3 minutes)
\item \textbf{run.py}: schedules 10 nights starting from 2021/01/01. It also updates the database after each night of scheduling is completed. log and numpy output of individual nights will be store in "/Output" directory, and the mp4 output of each night will be stored in "/Visualizations" directory (all takes around 10 minutes).
\end{enumerate}

%
%\begin{figure}
%\centering
%\includegraphics[width=0.8\textwidth, trim={5cm 0 0 0}, clip]{Figures/BldgBlock.pdf}
%\label{fig_qud}\caption{ }
%\end{figure}

%
%
%This report reflects the details of Feature-based Telescope Scheduler's design. Including the features, basis functions, hard constraints, cost function, and the performance function as they are at the end of Oct. 2016.
%
%In summary, there are seven features (\ref{sec_f}) for each field, with the total of 4206 fields that need to be evaluated at most at the end of each visit. Basis functions (\ref{sec_bf}) are designed to transform the raw features to decision criteria that are at the same time properly scaled and comparable to each other. There are seven Basis functions evaluated at the end of each visit for feasible fields upon which the decision is entirely based on. In other words, decision is independent of the time and the history of the observation, because all of the determining history dependent information is reflected in the Basis functions trough features.
%
%Two candidates for cost function is proposed in \ref{sec_cf}, \textit{Linear Cost Function}, and \textit{Quadratic Cost Function}. The former cost function is what we used in the earlier versions of the scheduler, and the latter cost function is introduced for the first time in this report. In \ref{sec_comp} it is shown that the Quadratic Cost Function outperforms the Linear Cost Function (in the current setting of the scheduler). Performance Function (\ref{sec_perf}) that measures the quality of a sequence of visits reflects the performance of the scheduler after a night of telescope's operation with the scheduler. Current performance function is a scalar value evaluated by linear combination of six different criteria. Section \ref{sec_opt} explains the details of training procedure of the Cost Function's parameters for both Linear and Quadratic candidates.
%%Finally, this report is concluded with a list of next step's improvements and additions that are to be made to the Feature-based Scheduler.
%
%\begin{center}
%\textbf{Key terms and notations}\
%\noindent\rule{\textwidth}{0.4pt}
%\end{center}
%\begin{tabular}{ l l  }
%$t$& GMT time in Julian Date,\\ %$2459215.5 \leq t \leq 2462867.5$ i.e. from January 1, 2021, to January 1, 2031\\
%$\tau_s(t)$& beginning of the night that $t$ lies in,\\
%$\tau_e(t)$& end of the night that $t$ lies in,\\
%$id(t)$& ID of the field that is visited at $t$, $i \in \{1,2,3,...,4206\},$\\
%$\theta_{l}(i,t)$& time of the last visit of field $i$ before $\tau_s(t)$, $\theta_{l}(i,t) = \infty$ if field $i$ is not visited before $\tau_s(t)$,\\
%$\theta_{l}^N(i,t)$& time of the last visit of field $i$ between $\tau_s(t)$ and $t$, $\theta_{l}^N(i,t) = \infty$ if field $i$ is not visited in this interval,\\
%$n^N(i,t)$ & number of the visits of field $i$ between $\tau_s(t)$ and $t$, $0 \leq n^N(i,t) \leq 3$\\
%$SM_{i,j}$& slew time from field $i$ to field $j$, $SM \in \mathbb{R}^{4206 \times 4206}$ is a given slew matrix,\\
%$alt(i,t)$ & altitude of the center of field $i$ at $t$, $-\frac{\pi}{2} \leq alt(i,t) \leq \frac{\pi}{2}$,\\
%$ha(i,t)$ & hour angle of the center of field $i$ at $t$, $-12 \leq ha(i,t) \leq 12$\\
%$cd(i,t)$ & co-added depth, measure of the cumulative information of collected from field $i$ in visits before $\tau_s(t)$,\\
%$\tau_{rise}(i,t)$ & rising time of field $i$ above the 1.4 airmass horizon at current night, $\tau_{rise}(i,t) = -\infty$ if $i$ never sets down,\\
%$\tau_{set}(i,t)$ & setting time of field $i$ below the 1.4 airmass horizon at current night, $\tau_{set}(i,t) = \infty$ if $i$ never sets down,\\
%$M_{\phi}(t)$ & percent of the Moon's surface illuminated at $t$,\\
%$M_{sep}(i,t)$ & Moon's separation from field $i$ at $t$, $0 \leq M_{sep}(i,t) \leq \pi$,\\
%$W_1, W_2$ & given constant time window in which a revisit is valid, $0 < W_1 < W_2$\\
%\end{tabular}\\
%\noindent\rule{\textwidth}{0.4pt}\\
%\newpage
%\section{Features}\label{sec_f}
%
%\begin{itemize}
%
%\item Slew time from field $ID(t)$ to field $i = 1 \dots 4206$\\
%\begin{center}
%$f_1(i,t) := SM_{id(t), i}$
%\end{center}
%
%\item $f_2(i,t)$ summarizes the history of visits of field $i$ into two elements, $f_2^1$, time past since the last visit before $\tau_s(t)$, and $f_2^2$, time past since the last visit after $\tau_s(t)$. The first element reflects the overall urgency of a visit for field $i$, and the second element need to be known to revisit a field in a valid window during a night. $f_2$ is a key feature in the sense that it detaches the decision of time $T$ from all $t < T$. However, the perfect decision requires a full information of the history, therefore the decision based on $f_2$ is only an approximation of the perfect decision. In other words, the original time dependent system is approximated by a Markovian system in which only the most important information of the history is taken into account. Of course, at any point that more details from history was critical for the decision, we have to extend the definition of $f_2$, that would, however, add a non-negligible computational cost to the training procedure.
%
%\begin{center}
%$f_2(i,t) = (f_2^1(i,t), f_2^2(i,t)) := (t - \theta_l(i,t), t - \theta_l^N(i,t))$
%\end{center}
%\item Altitude of the field is a determining factor in the quality of the visit, therefore one of the features, $f_3$, is devoted to bring this information to the decision making procedure.
%\begin{center}
%$f_3(i,t) := alt(i,t)$
%\end{center}
%\item Although high altitudes are preferable for observation, but depend on the declination there is a threshold for each field's altitude. Therefore, what actually matters is whether a field is visited in the highest altitude it can ever reach. This information can be extracted from Hour Angle, $f_4$, of a field (that is preferred to be close to 0).
%\begin{center}
%$f_4(i,t) := ha(i,t)$
%\end{center}
%\item Co-added depth, $f_5$, offers feedback information to the decision making procedure. For each field, this feature measures the overall quality of the visits of field $i$, before $t$, that the overall urgency of visiting field $i$ at $t$ is depend upon. The fact that the co-added depth measure is a computationally expensive evaluation that involves heavy image processing, has a minimal negative effect on the scheduling performance. Because, the total number of visits of a given field is a lot more than 3 times (maximum number of visits at a single night), in addition, there is a separation of 2 to 3 nights between visits of a field that occurs at different nights, therefore, updates of the co-added depth values can be delayed by 2 to 3 days without a noticeable negative effect to the scheduling performance.
%\begin{center}
%$f_5(i,t) := cd(i,t)$
%\end{center}
%\item $f_6$ reflects the duration of future visibility of a field that determines its same night revisit urgency, and is defined to detached the decision of time $T$ from all $t >T$.
%\begin{center}
%$f_6(i,t) := \begin{cases} \tau_{set}(i,t) - t,& \text{if } \tau_{rise}(i,t) < t \\ 0,  & \text{otherwise} \end{cases}$
%\end{center}
%
%\item $f_7$ is the background sky brightness, which temporarily is defined by two important parameters that determine the sky brightness, the Moon phase and its separation from field $i$ at $t$.
%\begin{center}
%$f_7(i,t) := (f_7^1(t), f_7^2(i,t)) := (M_{\phi}(t), M_{sep}(i,t))$
%\end{center}
%\end{itemize}
%
%\section{Basis functions}\label{sec_bf}
%Basis functions are mainly designed to scale the features and reflect their direct or inverse relation with the overall cost of a visit. There has been minimum effort put on crafting the basis functions. Of course an engineered design by experts would result in a more desirable model that offers a space of search for optimization algorithm which contains better optimums with higher probability. But in the current version of the scheduler, most of the efforts to find an optimum solution is assumed to be done by the optimization part rather than the design of hand crafted basis functions.
%
%\begin{itemize}
%\item Scaled slew time from $ID(t)$ to $i$, it is scaled in a way that the most frequent values lie between about 3 to 5.
%\begin{center}
%$F_1(f_1(i,t)) = \frac{f_1(i,t)}{5 ~sec},$
%\end{center}
%\item $F_2$ is designed to reflect the urgency of the same night revisit of field $i$ at time $t$. The least urgent situation is when a field has never been visited ($n^N(i,t) = 0$), or it has already received its second visit ($n^N(i,t) = 2$), in this case, $F_2$ as an element of cost function, takes its maximum value. A moderately urgent case is when a field is visited only once and needs a second visit at the same night, but it will be visible for more than 30 minutes. Finally, the most urgent case is when a field is visited only once and it will be visible less than 30 minutes, in which $F_2$ takes its minimum value to pose the least contribution to the cost of visiting such field.
%\begin{center}
%$F_2(n^N(i,t), f_2^2(i,t), f_6(i,t)) = \begin{cases}  5 & \text{if } n^N(i,t) \in \{0,2\},\\ 5\times (1-\exp(-0.000694 f_2^2(i,t))) & \text{if } n^N(i,t) = 1 \text{ and } f_6(i,t) \geq 30~minutes,\\ 0& \text{if } n^N(i,t) = 1 \text{ and } f_6(i,t) < 30~minutes, \end{cases}$
%\end{center}
%\item $F_3$ reflects the overall urgency of visiting field $i$ at $t$, by simply reversing the time past from last visit of $i$ before $\tau_s(t)$.
%\begin{center}
%$F_3(f_2^1(i,t)) = \frac{1}{f_2^1(i,t)},$
%\end{center}
%\item For $F_4$,  first the altitude $f_3$ is normalized between 0 to 1, then subtracted from 1 to reflect its relationship to the cost of the visit.
%\begin{center}
%$F_4(f_3(i,t)) = (1 - \frac{2 f_3(i,t)}{\pi}),$
%\end{center}
%\item To make sure that we wont undermine a field because of its declination that doesn't let it reach higher altitudes, $F_5$ is designed to assign a same cost to fields with the same separation from the meridian, hence from the highest altitude they can ever reach.
%\begin{center}
%$F_5(f_4(i,t)) = |\frac{ f_4(i,t)}{12}|,$
%\end{center}
%\item $F_6$ is the normalized co-added depth, $f_5$, that increasingly grow throughout the telescope's years of operation.
%\begin{center}
%$F_6(f_5(i,t)) = \frac{f_5(i,t)}{\max\limits_i(f_5(i,t)) +1},$
%\end{center}
%\item $F_7$ is a normalized measure of brightness of the sky in the background of field $i$, at $t$. It is temporarily designed to adopt the Moon phase, $f_7^1$, and the Moon separation, $f_7^2$ to return a value between 0 to 1 as a measure of brightness.
%\begin{center}
%$F_7(f_7(i,t)) = \begin{cases} \exp(-\frac{10}{\pi} f_7^2(i,t)),  & \text{if }  0 \leq f_7^1(t) < 0.2 \\ \exp(-\frac{2}{\pi} f_7^2(i,t)),  & \text{if }  0.2 \leq f_7^1(t) < 0.5\\ \exp(-\frac{1}{\pi} f_7^2(i,t)),  & \text{if }  0.5 \leq f_7^1(t) < 0.8 \\ 1- \frac{f_7^2(i,t)}{2 \pi},  & \text{otherwise}\end{cases}$
%\end{center}
%\end{itemize}
%
%\section{Feasibility}\label{sec_feas}
%
%\begin{defn*} $\sigma_t \subset \{1,2,\dots, 4206\}$ is the set of all feasible fields at $t$. Field $i \in \sigma_t$ if and only if:
%\begin{enumerate}
%\item $ \tau_{rise}(i,t) \leq t \leq \tau_{set}(i,t) $ (field $i$ has to be above 1.4 airmass horizon at $t$)
%\item $f_2^2(i,t) = -\infty$ ($i$ is not visited between $\tau_s(t)$ and $t$) or $W_1 \leq f_2^2(i,t) \leq W_2$ (time past since the last visit has to lie in the valid revisit window)
%\item $n^N(i,t) \leq 2$ ($i$ is not visited more than twice between $\tau_s(t)$ and $t$)
%\item  $f_1(i,t) \leq 20~sec$ (slew time from $ID(t)$ to $i$ is less than 20 seconds)
%\item $M_{sep}(i,t) \geq 30~deg$ (field $i$ is at least 30 degrees separated from the Moon)
%\end{enumerate}
%\end{defn*}
%
%
%\section{Cost function}\label{sec_cf}
%
%Linear Cost Function is a linear combination of the Basis Functions, with coefficients $c = [c_1,\dots, c_7]$ that are determined by the offline optimization algorithm.\\
%
%For the $j^th$ decision made at $t_j$:
%\begin{center}$CF_l(j) = \sum\limits_{k=1}^7  c_k F_k(i,t_j),$\end{center}
%
%Quadratic Cost Function contains both linear terms and pairwise quadratic terms of the Basis Functions, with 56 coefficient. Considering the quadratic terms offers a more flexible structure that exploits possible correlation of the different Basis Functions which defines a larger space of search for best coefficients, hence possibly a better solution. On the other hand, this eight times larger search space requires more computational resources.
%
%For the $j^th$ decision made at $t_j$:
%\begin{center} $CF_q(j) = \sum\limits_{k=1}^7  c_k F_k(i,t_j) + \sum\limits_{k=1}^m \sum\limits_{l=1}^m  d_{kl} F_k(i,t_j) F_l(i,t_j) ,$\end{center}
%
%Note that both functions are linear with respect to their free parameters.
%
%\section{Decision Function}\label{sec_df}
%
%For the $j^th$ decision made at $t_j$:\\
%\begin{center}  $ID(t_j)= \text{argmin}_{\sigma_{t_j} }CF(j),$\end{center}
%
%
%\section{Performance Function}\label{sec_perf}
%
%Current performance function is defined over a night of observation between $t_0 = 2457633.489641$ (2016/9/1 23:45:05 GMT), and $T = 2457633.892419$ (2016/9/2 09:25:05 GMT). Let $N_v$ be the number of visits between $t_0$ and $T$, then,
%
%\begin{center}
%$P(t_0,T) = \frac{1}{N_v}( P_1 \sum\limits_{j = 1}^{N_v} CF(j) +P_2 \sum\limits_{j = 1}^{N_v} f_1(ID(t_j),t_j) +P_3 \sum\limits_{j = 1}^{N_v} f_3(ID(t_j),t_j)) + \frac{1}{T-t_0}(P_4N_{triple} + P_5 N_{double} + P_6 N_{single})$
%\end{center}
%
%Where, $N_{triple}, N_{double}, \text{and } N_{single}$ are the number of fields visited three, two, and one time(s) respectively, between $t_0$ and $T$.
%
%For the current version of the training algorithm, preference parameters are set as follow:\\
%
%$P = [P_1,\dots,P_6] = [-1,-1,4,0,3,-10]$
%
%\section{Optimization}\label{sec_opt}
%
%Differential Evolution (DE) algorithm explores and exploits a finite space of solutions and returns the solution by which a scalar objective function is maximized amongst all visited points. DE never guarantees a 100\% global optimality. However increasing the number of trials and iterations increases confidence in the global optimality of the solution.
%
%To find the parameters of cost function, first we randomly initialize $N_p$ different sets of parameters. Then, let each of the settings run the LSST simulator, for a night of observation. Then we measure the scalar performance function $P(t_0,T)$. Based on the values of the parameters and objective function, DE, suggests a set of new $N_p$ controllers which on average work better than the previous controllers. Then iterates this procedure, until there is no improvement in the best observed performance. A pseudo code of the basic DE algorithm can be found in Appendix \ref{app_code}.
%
%To be able to compare the performance of Linear Cost Function versus Quadratic Cost Function, instead of terminating the training based on the performance function progress (that is not known until the end of the training), we limited the number of iterations to 20 (smaller than the expected number of iterations in the normal termination setting), with $N_p = 50$. This modification allocates a same computational budget for both cost functions. (Elapsed time: 12 hours, CPU 1.6 GHz Intel Core i5)
%
%Best solution found for Linear Cost Function:\\
%\indent $c = [1.3, 9.8, 5.2, 6.4, 0.16, 7.11, 8.7]$
%
%Best solution found for Quadratic Cost Function:\\
%\indent $c = ~[4.2,  ~~7.3,  ~~3.2, ~~ 7.4, ~~ 2.5,~~  2.3, ~~2.1]$\\
%\indent $d = \begin{bmatrix}
%0.61&   4.1& 1.9& 8.5& 4.7& 8.3&  4.7\\
%2.8 &  6.6 &  3.9& 5.6& 4.0& 5.6&  4.0\\
%7.9 & 8.0 &  2.0& 6.4 & 5.3& 5.4&  5.8\\
%6.5& 5.8&6.8&   4.8& 4.8& 4.5&  1.4\\
%6.7& 2.5&4.5& 5.3& 8.0&  4.6& 4.1\\
%2.0&  4.6& 4.3& 3.6& 4.9&  5.9& 9.3\\
%1.4& 9.2& 3.6&3.2&4.2&7.2& 6.2
%\end{bmatrix}$
%
%
%\section{Simulation results and comparison}\label{sec_comp}
%
%In this section four different simulations are presented:
%\begin{itemize}
%\item $S_1:$ 100 days of scheduling with the Linear Cost Function starting from 2016/9/1
%\item $S_2:$ 100 days of scheduling with the Quadratic Cost Function starting from 2016/9/1
%\item $S_3:$ 365 days of scheduling with the Linear Cost Function starting from 2016/9/1
%\item $S_1:$ 315 days of scheduling with the Quadratic Cost Function starting from 2016/9/1
%\end{itemize}
%
%\subsection{Simulation timing}
%A trained Feature-based scheduler contains four different phases:
%
%\begin{enumerate}
%\item \textbf{Preprocessing and data generation} generates lookup tables for predictable data such as altitude to avoid evaluation of them in on-line scheduling. This phase also process the history of the observation and returns the summarized information that we use as a substitute for looking into the history. Time required for this phase is currently depend on the length of history, however it can be optimized to become independent of the size of past scheduling sequence, that would take up to 20 seconds for each individual night.
%\item \textbf{Import data} is to read the data generated at the previous phase, and it takes about 13 seconds.
%\item \textbf{Online scheduling} is the heart of the scheduler that makes the sequential decisions, and it takes about 70 seconds, but it is linearly dependent on the length of the night.
%\item \textbf{Writing on the database} record the data into the database and it takes up to 2 seconds.
%\end{enumerate}
%
%Timings are based on the simulation runs on a 1.6 GHz Intel Core i5 CPU with 4 GB 1600 MHz DDR3, which sums up to 105 seconds for each night of scheduling.
%
%Table \ref{tab_sim} demonstrates the most important statistics of the output of above-mentioned simulations. In terms of the number of visits Quadratic Cost function outperforms the Linear Cost Function with 0.4 visit per hour (1460 visit per year). Superiority of the Quadratic Cost Function is not noticeable in the average of visits altitude, however, comparing the average value with the best night and the worst night shows that it offers a more consistent performance over different nights compare to the Linear Cost Function.
%
%\begin{table}
%\label{tab_sim}\caption{Simulation statistics}
%\begin{tabular}{l c c | c c}
%Simulation            & $S_1$ & $S_2$ & $S_3$ & $S_4$  \\
%\hline
%number of visits per hour      				& 103.74 & \textbf{104.16} & 103.71 & \textbf{104.17}  \\
%ratio of the triple visits to total number of visits   & 0.29 & 0.25 & 0.29 & 0.25\\
%ratio of the double visits to total number of visits &0.57 & \textbf{0.62} & 0.56 & \textbf{0.61}\\
%ratio of the single visits to total number of visits  & 0.15 & \textbf{0.13} & 0.15 & \textbf{0.14}\\
%\hline
%average altitude of all visits (deg) 				 & 67.35&\textbf{67.86}&66.84&\textbf{67.40}\\
%highest altitude average of a night of simulation &79.97&76.74&79.97&76.74\\
%lowest altitude average of a night of simulation &59.97&61.69&58.64&59.49\\
%average slew time of all visits (sec) 				 & \textbf{4.27}&4.58&4.73&\textbf{4.58}\\
%lowest slew time average of a night of simulation &4.43&4.39&4.43&4.39\\
%highest slew time average of a night of simulation &5.07&4.86&5.07&4.94\\
%\hline
%median number of visits of a field normalized by the simulation length 			& 0.29&0.31& 0.30&0.29\\
%average number of visits of a field normalized by the simulation length 			&0.35&0.36&0.28&0.28\\
%median of the time separation between $1^{st}$ and $2^{nd}$ visits& 16.17 & 15.71&16.20& 16.07\\
%median of the time separation between $2^{nd}$ and $3^{rd}$ visits& 18.43 & 18.71&18.81& 18.80\\
%\end{tabular}
%\end{table}
%%op:  with Linear Cost Function over 365 nights. bottom
%
%Figures \ref{fig_lin} and \ref{fig_qud}, show the visit statistics of Linear Cost Function and Quadratic Cost Function respectively. Histogram presents the distribution of the frequency of visits of a field which we ideally prefer to be as concentrated as possible (uniform coverage of the sky). The bottom bar graphs show the number of visits of each field, $i = 1\dots4206$, which we prefer to be as uniformly distributed as possible.
%
%\begin{figure}\label{fig_lin}
%\centering
%\includegraphics[width=0.8\textwidth ]{Figures/Linear365.png}
%\label{fig_lin}\caption{Linear Cost Function}
%\end{figure}
%
%\begin{figure}
%\centering
%\includegraphics[width=0.8\textwidth]{Figures/Quad315.png}
%\label{fig_qud}\caption{Quadratic Cost Function}
%\end{figure}
%
%\newpage
%\appendix
%
%\section{Basic Differential Evolution Algorithm}\label{app_code}
%Notation:\\
%$C{r}$: Crossover rate,\\
%$F$: Mutation factor,\\
%$N_p$: Population size,\\
%$\ax^{L}$: Initialization lower bound, (not necessarily a lower bound on the solution.)\\
%$\vec{\rho}\mid^{1}_{0}$: Uniformly random value between 0 and 1,\\
%$\ax^{u}$: Initialization upper bound, (not necessarily an upper bound on the solution.)\\
%$\ax_{i}^{(0)}$: Initial individuals,\\
%
%{\footnotesize
%\hrule
%\begin{tabbing}
%\hspace{0.5cm} \= \hspace{0.5cm} \=  \hspace{0.5cm} \= \hspace{0.5cm} \=\\
%\textbf{begin} \\
%\> Initialize algorithm settings: $C{r}$, $F$\\
%\> \textbf{for} ($i=1,\ldots,N_{p}$) \\
%
% \> \> $P^{(0)}\leftarrow \ax_{i}^{(0)}=\ax^{L}+\vec{\rho}\mid^{1}_{0}(\ax^{U}-\ax^{L})$~~\textbf{end} ~~\% \verb"Initialize" \\
%
%\> \textbf{while} (not optimal) \textbf{do begin} \\
%
% \>  \textbf{for} ($i=1,\ldots,N_{p}$) \textbf{do begin}~~\% \verb"Perform mutation" \\
%
% \> \> $\vec{u}_{i}^{k+1}\leftarrow$ \textbf{mutate} \\
%
% \> \>  \textbf{for} ($j=1,\ldots,N_{p}$) \textbf{do begin} ~~\% \verb"Crossover with target" \\
%
% \> \> \> \textbf{if} $\rho\mid_{0}^{1} < C{r}$ \textbf{do begin}\\
%
% \> \> \> \> $u_{ij}^{k+1} \leftarrow x_{ij}^{k}$~~\textbf{end} \\
%
% \> \> \textbf{end} \\
%
% \> \> $\ax_{i}^{k+1}\leftarrow$ \textbf{selection} $[\ax_{i}^{k},\vec{u}_{i}^{k+1}]$ ~~\% \verb"Perform selection" \\
%
% \> \textbf{end} \\
%
%$k \leftarrow k+1$ \\
%\textbf{end}
%\end{tabbing}
%\hrule}
%
%

\newpage
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\end{document}


\section{Programming language}

We define a programming language that is both simple and powerful enough to conclusively describe weak memory models to the extent they may be available to the programmer. Throughout this work, we will refer to this language as SALPL, abbreviating the first description of the ``simple assembly-like programming language'' \cite{kupersteinetal10} defined by Kuperstein, Vechev and Yahav in \cite{kupersteinetal10}, on which SALPL is based. A SALPL program has only integer-type variables, but it can perform comparisons that return boolean values, which in turn can be operated on using boolean operators. Boolean values are used in conditionals and may have the values $true$, $false$, or $*$, all of which are also valid literals. Comments are defined as in C, with \lstinline{//} prepending line comments and \lstinline{/*} and \lstinline{*/} enclosing block comments.\\

In this section, we will group code placeholders using $[\:]$-brackets, which might have a * appended for an arbitrary number of the code specified.

\paragraph{Accepting program state}

A valid SALPL program must have the following structure:

\begin{lstlisting}[frame=single, mathescape]
beginit
	$[store\:statement]*$
endinit

$[process\:declaration]*$

$[assertion]$
\end{lstlisting}

\paragraph{Assertion}

The assertion may be appended to the end of the program. Its syntax is derived from the boolean program syntax used by the Fender \cite{fender} model checker. The boolean expression therein may only refer to global variables, constants, or program counters of the form \lstinline$pc($$i$\lstinline$)$, with $i$ being a valid process index. The value of a program counter may be that of any valid label of the process $i$.

\begin{lstlisting}[frame=single, mathescape]
assert(always($boolean\:expression$))
\end{lstlisting}

\paragraph{Process declaration}

Every process must have a unique integer identifier $i$.

\begin{lstlisting}[frame=single, mathescape]
process $i$:
	$[statement]*$
\end{lstlisting}

\paragraph{Statement}
A $statement$ can be any of the following: \emph{store statement}, \emph{load statement}, \emph{local assignment statement}, \emph{label}, \emph{goto statement}, \emph{flush statement}, \emph{fence statement}, \emph{abort statement}, \emph{nop statement}, \emph{if-else block}.

\paragraph{Store statement}
Generally, the store statement writes the right-hand side expression to the buffer, pending commitment to remote memory. In the special case where flushes are to be excluded, as it will be the case later on in this work, the store statement may be viewed as an immediate and deterministic remote write operation. The left-hand side identifier must be a global variable.

\begin{lstlisting}[frame=single, mathescape]
store $variable\:identifier$ = $integer\:expression$;
\end{lstlisting}

\paragraph{Load statement}
Generally, the load statement reads the most recent relevant value from the buffer, and it only reads from remote memory if the buffer doesn't contain any values of the desired variable. In the special case where flushes are to be excluded, as it will be the case later on in this work, the load statement may be viewed as an unconditional remote read operation. The left-hand side identifier must be a local variable, while the right-hand side identifier must be a global variable.

\begin{lstlisting}[frame=single, mathescape]
load $variable\:identifier$ = $variable\:identifier$;
\end{lstlisting}

\paragraph{Local assignment statement}
The left-hand side identifier must be a local variable. The \emph{integer expression} may be an integer literal, an integer variable symbol, or any integer operation on them.

\begin{lstlisting}[frame=single, mathescape]
$variable\:identifier$ = $integer\:expression$;
\end{lstlisting}

\paragraph{Label}
The statement following the colon may not be another label. The label value $i$ must be unique within its process.

\begin{lstlisting}[frame=single, mathescape]
$i$: $statement$
\end{lstlisting}

\paragraph{Goto statement}
The label value $i$ must be a valid label within the calling process.

\begin{lstlisting}[frame=single, mathescape]
goto $i$;
\end{lstlisting}

\paragraph{Flush statement}
Flushing will iterate through all global variables and non-deterministically commit the first value of the respective variable to remote memory and remove that value from the buffer. If a variable does not have any values to be committed, it will be ignored.

\begin{lstlisting}[frame=single, mathescape]
flush;
\end{lstlisting}

\paragraph{Fence statement}
Without any operations on the buffer or memory, fences just assume the buffer to be empty from then on. If the buffer is not empty, the fence blocks until it becomes empty.

\begin{lstlisting}[frame=single, mathescape]
fence;
\end{lstlisting}

\paragraph{Abort statement}
Aborts the program with the $message$ argument as the error message.

\begin{lstlisting}[frame=single, mathescape]
abort("$message$");
\end{lstlisting}

\paragraph{Nop statement}
Does nothing.

\begin{lstlisting}[frame=single, mathescape]
nop;
\end{lstlisting}

\paragraph{If-else block}
If the \emph{boolean expression} evaluates to \emph{true}, the \emph{statement} block right after the conditional is carried out, omitting the \emph{else block}, if it exists. If it evaluates to \emph{false}, jumps to the point after the first \emph{statement} block. If it evaluates to \lstinline$*$, i.e. \emph{undecided}, it will non-deterministically simulate an evaluation to either \emph{true}, or \emph{false}.

\begin{lstlisting}[frame=single, mathescape]
if ($boolean\:expression$)
	$[statement]*$
$[else\:block]?$
endif;
\end{lstlisting}

with the \emph{else block} being:

\begin{lstlisting}[frame=single, mathescape]
else
	$[statement]*$
\end{lstlisting}


\chapter{\label{chap:interpolation}Some notes on the interpolation}

In \wannier{} v.2.1, a new flag {\tt use\_ws\_distance} has been
introduced. Setting it to {\tt .false.} reproduces the
``standard'' behavior of \wannier{} in v.2.0.1 and earlier,
while setting it to {\tt .true.} changes the interpolation method
as described below. In general, this allows a smoother interpolation,
helps reducing (a bit) the number of $k-$points required for interpolation,
and reproduces the band structure of large supercells sampled at $\Gamma$
only (setting it to {\tt .false.} produces instead flat bands, which
might instead be the intended behaviour for small molecules carefully
placed at the centre of the cell).

The core idea rests on the fact that the Wannier functions $w_{n\bvec{R}}(\bvec{r})$
that we build from $N\times M\times L$ $k-$points are actually periodic
over a supercell of size $N\times M\times L$, but when you use
them to interpolate you want them to be \emph{zero} outside this supercell.
In 1D it is pretty obvious want we mean here, but in 3D what you really
want that they are zero outside the Wigner--Seitz cell of the
$N\times M\times L$ superlattice.

The best way to impose this condition is to check that every real-space
distance that enters in the $R\to k$ Fourier transform is the shortest possible
among all the $N\times M\times L-$periodic equivalent copies.

If the distances were between unit cells, this would be trivial, but the
distances are between Wannier functions which are not centred on $\bvec R=0$.
Hence, when you want to consider the matrix element of a generic operator $\bvec O$
(i.e., the Hamiltonian)  $\langle w_{i\bvec 0}(\bvec{r})|\bvec{O}|w_{j\bvec{R}}(\bvec{r})\rangle$
you must take in account that the centre $\bvec{\tau}_i$ of $w_{i\bvec 0}(\bvec{r})$ may
be very far away from $\bvec{0}$ and the centre $\bvec{\tau}_j$ of $w_{j\bvec{R}}(\bvec{r})$
may be very far away from $\bvec{R}$.

There are many way to find the shortest possible distance between $w_{i\bvec{0}}(\bvec{r})$ and
$w_{j\bvec{R}}(\bvec{r}-\bvec{R})$, the one used here is to consider the distance
$\bvec{d}_{ij\bvec{R}} = \bvec{\tau}_i - (\bvec{\tau}_j+\bvec{R})$
and all its superlattice periodic equivalents
$\bvec{d}_{ij\bvec{R}}+ \bvec{\tilde R}_{nml}$, with
$\bvec{\tilde R}_{nml} = (Nn\bvec{a}_1 + Mm\bvec{a}_2 + Ll\bvec{a}_3)$
and $n,l,m = {-3,-2,...0,...3}$.

Then,
\begin{enumerate}
\item if $\bvec{d}_{ij\bvec{R}}+ \bvec{\tilde R}_{nml}$ is inside the
  $N\times M \times L$ super-WS cell, then it is the shortest, take it and quit

\item if it is outside the WS, then it is not the shortest, throw it away

\item if it is on the border/corner of the WS then it is the shortest, but there
are other choices of $(n,m,l)$ which are equivalent, find all of them
\end{enumerate}

Because of how the Fourier transform is defined in the \wannier{} code (not the only
possible choice) it is only $\bvec{R}+\bvec{\tilde R}_{nml}$
that enters the exponential, but you still have to consider the distance
among the actual centres of the Wannier functions. Using
the centres of the unit-cell to which the Wannier functions belong
is not enough (but is easier, and saves you one index).

Point 3 is not stricly necessary, but using it helps enforcing the
symmetry of the system in the resulting band structure. You
will get some small but evident symmetry breaking in the band
plots if you just pick one of the equivalent $\bvec{\tilde R}$ vectors.

Note that in some cases, all this procedure does absolutely nothing,
for instance if all the Wannier function centres are very close to 0
(e.g., a molecule carefully placed in the periodic cell).

In some other cases, the effect may exist but be imperceptible. E.g.,
if you use a very fine grid of $k-$points, even if you don't centre
each functions perfectly, the periodic copies will still be so far away
that the change in centre applied with $\tt use\_ws\_distance$ does not matter.

When instead you use few $k-$points, activating the $\tt use\_ws\_distance$
may help a lot in avoiding spurious oscillations of the band structure
even when the Wannier functions are well converged.


% This LaTeX was auto-generated from an M-file by MATLAB.
% To make changes, update the M-file and republish this document.

      \subsection{gp1.m}

\begin{par}
\textbf{Summary:} Compute joint predictions for the FITC sparse approximation to multiple GPs with uncertain inputs. Predictive variances contain uncertainty about the function, but no noise. If gpmodel.nigp exists, individual noise contributions are added.
\end{par} \vspace{1em}
\begin{verbatim}function [M, S, V] = gp1d(gpmodel, m, s)\end{verbatim}
\begin{par}
\textbf{Input arguments:}
\end{par} \vspace{1em}
\begin{verbatim}gpmodel    GP model struct
  hyp      log-hyper-parameters                                  [D+2 x  E ]
  inputs   training inputs                                       [ n  x  D ]
  targets  training targets                                      [ n  x  E ]
  nigp     (optional) individual noise variance terms            [ n  x  E ]
m          mean of the test distribution                         [ D  x  1 ]
s          covariance matrix of the test distribution            [ D  x  D ]\end{verbatim}
\begin{par}
\textbf{Output arguments:}
\end{par} \vspace{1em}
\begin{verbatim}M          mean of pred. distribution                            [ E  x  1 ]
S          covariance of the pred. distribution                  [ E  x  E ]
V          inv(s) times covariance between input and output      [ D  x  E ]\end{verbatim}
\begin{par}
Copyright (C) 2008-2013 by Marc Deisenroth, Andrew McHutchon, Joe Hall, and Carl Edward Rasmussen.
\end{par} \vspace{1em}
\begin{par}
Last modified: 2013-03-05
\end{par} \vspace{1em}

\subsection*{High-Level Steps}

\begin{enumerate}
\setlength{\itemsep}{-1ex}
   \item If necessary, compute kernel matrix and cache it
   \item Compute predicted mean and inv(s) times input-output covariance
   \item Compute predictive covariance matrix, non-central moments
   \item Centralize moments
\end{enumerate}

\begin{lstlisting}
function [M, S, V] = gp1(gpmodel, m, s)
\end{lstlisting}

\subsection*{Code}

\begin{lstlisting}
if ~isfield(gpmodel,'induce') || numel(gpmodel.induce)==0,
    [M, S, V] = gp0(gpmodel, m, s); return; end

persistent iK iK2 beta oldX;
ridge = 1e-6;                        % jitter to make matrix better conditioned
[n, D] = size(gpmodel.inputs);    % number of examples and dimension of inputs
E = size(gpmodel.targets,2);         % number of examples and number of outputs
X = gpmodel.hyp; input = gpmodel.inputs; targets = gpmodel.targets;

[np pD pE] = size(gpmodel.induce);     % number of pseudo inputs per dimension
pinput = gpmodel.induce;                                   % all pseudo inputs

% 1) If necessary: re-compute cached variables
if numel(X) ~= numel(oldX) || isempty(iK) || isempty(iK2) || ... % if necessary
              sum(any(X ~= oldX)) || numel(iK2) ~=E*np^2 || numel(iK) ~= n*np*E
  oldX = X;                                        % compute K, inv(K), inv(K2)
  iK = zeros(np,n,E); iK2 = zeros(np,np,E); beta = zeros(np,E);

  for i=1:E
    pinp = bsxfun(@rdivide,pinput(:,:,min(i,pE)),exp(X(1:D,i)'));
    inp = bsxfun(@rdivide,input,exp(X(1:D,i)'));
    Kmm = exp(2*X(D+1,i)-maha(pinp,pinp)/2) + ridge*eye(np);  % add small ridge
    Kmn = exp(2*X(D+1,i)-maha(pinp,inp)/2);
    L = chol(Kmm)';
    V = L\Kmn;                                             % inv(sqrt(Kmm))*Kmn
    if isfield(gpmodel,'nigp')
      G = exp(2*X(D+1,i))-sum(V.^2)+gpmodel.nigp(:,i)';
    else
      G = exp(2*X(D+1,i))-sum(V.^2);
    end
    G = sqrt(1+G/exp(2*X(D+2,i)));
    V = bsxfun(@rdivide,V,G);
    Am = chol(exp(2*X(D+2,i))*eye(np) + V*V')';
    At = L*Am;                                    % chol(sig*B) [thesis, p. 40]
    iAt = At\eye(np);
% The following is not an inverse matrix, but we'll treat it as such: multiply
% the targets from right and the cross-covariances left to get predictive mean.
    iK(:,:,i) = ((Am\(bsxfun(@rdivide,V,G)))'*iAt)';
    beta(:,i) = iK(:,:,i)*targets(:,i);
    iB = iAt'*iAt.*exp(2*X(D+2,i));              % inv(B), [Ed's thesis, p. 40]
    iK2(:,:,i) = Kmm\eye(np) - iB; % covariance matrix for predictive variances
  end
end

k = zeros(np,E); M = zeros(E,1); V = zeros(D,E); S = zeros(E);       % allocate
inp = zeros(np,D,E);

% 2) Compute predicted mean and inv(s) times input-output covariance
for i=1:E
  inp(:,:,i) = bsxfun(@minus,pinput(:,:,min(i,pE)),m');

  L = diag(exp(-X(1:D,i)));
  in = inp(:,:,i)*L;
  B = L*s*L+eye(D);

  t = in/B;
  l = exp(-sum(in.*t,2)/2); lb = l.*beta(:,i);
  tL = t*L;
  c = exp(2*X(D+1,i))/sqrt(det(B));

  M(i) = sum(lb)*c;                                            % predicted mean
  V(:,i) = tL'*lb*c;                     % inv(s) times input-output covariance
  k(:,i) = 2*X(D+1,i)-sum(in.*in,2)/2;
end

% 3) Compute predictive covariance matrix, non-central moments
for i=1:E
  ii = bsxfun(@rdivide,inp(:,:,i),exp(2*X(1:D,i)'));

  for j=1:i
    R = s*diag(exp(-2*X(1:D,i))+exp(-2*X(1:D,j)))+eye(D); t = 1./sqrt(det(R));
    ij = bsxfun(@rdivide,inp(:,:,j),exp(2*X(1:D,j)'));
    L = exp(bsxfun(@plus,k(:,i),k(:,j)')+maha(ii,-ij,R\s/2));
    if i==j
      S(i,i) = t*(beta(:,i)'*L*beta(:,i) - sum(sum(iK2(:,:,i).*L)));
    else
      S(i,j) = beta(:,i)'*L*beta(:,j)*t; S(j,i) = S(i,j);
    end
  end

  S(i,i) = S(i,i) + exp(2*X(D+1,i));
end

% 4) Centralize moments
S = S - M*M';
\end{lstlisting}


\documentclass[a4paper,11pt]{article}

\usepackage[T1]{fontenc} \usepackage{lmodern} \usepackage[utf8]{inputenc}
\usepackage[english]{babel} \usepackage{csquotes}
\usepackage{float} \usepackage{graphicx,subfigure}
\usepackage{amssymb,amsmath,epstopdf} %\usepackage{siunitx}
\usepackage[nodayofweek]{datetime}
\usepackage[top=3.0cm,bottom=2.0cm,left=2.5cm,right=2.5cm,headheight=30pt]{geometry}
\usepackage{natbib}
\usepackage{fancyhdr} \pagestyle{fancy} \usepackage{lastpage}
\usepackage{parskip} \setlength{\parskip}{.5em} \setlength{\parindent}{1em}
\usepackage[colorlinks=true,allcolors=blue]{hyperref} \hypersetup{
	pdfauthor={Michaël Defferrard, Soroosh Shafiee},
	pdftitle={Incremental Gradient Methods},
	pdfsubject={Project proposal}
}
\lhead{Advanced Topics in Data Sciences\\ Project report}
\chead{\hspace{2cm}EPFL\\ \hspace{2cm}\shortdate\today}
\rhead{Michaël \textsc{Defferrard}\\ Soroosh \textsc{Shafiee}}
\cfoot{}

\newcommand{\R}{\mathbb{R}}
\newcommand{\B}{\mathcal{B}}
\newcommand{\eqnref}[1]{(\ref{eqn:#1})}
\newcommand{\figref}[1]{Figure~\ref{fig:#1}}
\newcommand{\prox}{\textrm{prox}}
%\DeclareMathOperator*{\prox}{prox}

\begin{document}

\begin{center}
	\Large{\textbf{\textsc{Incremental Gradient Methods}}}
\end{center}

This project is aimed to be a way for us to better understand and thinker with
the recent advances in Stochastic Gradient Descent algorithms, specifically
the recent SAGA \cite{defazio_saga_2014}. This method is similar in spirit to
the previously developed SAG, SDCA, MISO and SVRG. This class of algorithms have
been developed to solve problems of the form
\begin{equation} \label{eqn:problem}
	\min_{x \in \R^d} \frac{1}{n} \sum_{i=1}^n f_i(x) + h(x),
\end{equation}
where each $f_i$ is convex and has Libschitz continuous derivatives with
constant $L$ or is strongly convex with constant $\mu$; and $h$ is a convex but
potentially non-differentiable function (his proximal operator is however easy
to compute). While computing the full gradient would be prohibitive due to large
$d$ and $n$, these iterative stochastic algorithms reduce the computational cost
of optimization by only computing the gradient of a subset of the functions
$f_i$ at each step.

Many machine learning problems can be cast in \eqnref{problem}, such as
(constrained) Least-Square or Logistic Regressions with $\ell_1$ or $\ell_2$
regularization; where $x$ would represent the model parameters, $f_i$ the data
fidelity term applied to a particular sample $i$, and $h$ a regularization or
indicator function of a convex set.

In this project we explored two approaches to improve SAGA towards two different
goals:
\begin{itemize}
	\item A \textbf{memory-efficient SAGA}, by way of computing and storing
		gradients over mini-batches instead of single samples, as is done for
		the infamous Stochastic Gradient Descent \cite{konevcny2014ms2gd}. It turns out that this
		approach is also faster than the original algorithm as it exploits the
		vectorial capabilities of modern processing units.
	\item A \textbf{time-efficient SAGA}, by way of distributing the gradient
		computation over many CPU cores while fusing the results and updating
		the model parameters on the master. The similar approach is also presented in \cite{lee2015distributed} for SVRG algorithm.
\end{itemize}

\section{SAGA algorithm} \label{sec1}

The algorithm starts with some known initial vector $x^0 \in \R^d$ and known
derivatives $f_i' (\phi_i^0) \in \R^d$ with $\phi_i^0 = x^0$ for each $i$. These
derivatives are stored in a table data-structure of length $n$, or alternatively
a $n \times d$ matrix. It uses a step size of $\gamma$\footnote{The authors
recommend a learning rate of $\gamma=1/(2(\mu n+L))$ in the strongly convex
case, $\gamma=1/(3(\mu n+L))$ if the strong convexity requirement only holds on
average and $\gamma=1/(3L)$ for non-strongly convex problems.} and, given the
value of $x^k$ and of each $f_i' (\phi_i^k)$ at the end of iteration $k$, makes
the following updates for iteration $k+1$:
\begin{enumerate}
\item Pick a $j$ uniformly at random.
\item Take $\phi_j^{k+1} = x^k$, and store $f_j'(\phi_j^{k+1})$ in the table.
	All other entries in the table remain unchanged. The quantity $\phi_j^{k+1}$
	is not explicitly stored.
\item Update $x$ using $f_j'(\phi_j^{k+1})$, $f_j'(\phi_j^k)$ and the table
	average:
	\begin{equation} \label{eqn:saga}
	w^{k+1} = x^k - \gamma \left[ f_j'(\phi_j^{k+1}) - f_j'(\phi_j^k)
	+ \frac1n \sum_{i=1}^n f_i'(\phi_i^k) \right] ,
	\end{equation}
	$$x^{k+1} = \prox_\gamma^h (w^{k+1}).$$
\end{enumerate}

As the authors of \cite{defazio_saga_2014}, we tested our algorithms by training
a linear regression model (with $\ell_1$ or $\ell_2$ regularization) on the
Million Song dataset\footnote{
\url{http://labrosa.ee.columbia.edu/millionsong}}. The problem, as stated on the
UCI repository\footnote{
\url{http://archive.ics.uci.edu/ml/datasets/YearPredictionMSD}} where the data
was downloaded from, is to predict the release year of a song from audio
features.

\section{Mini-batch SAGA}

We first form $\frac{n}m$ mini-batches $\{\B_i\}_{i=1}^{\frac{n}m}$ of size
$|\B_i| = m$ and take gradients w.r.t. them, such that the gradient matrix is of
size $\frac{n}m \times d$ instead of $n \times d$. The updates for iteration
$k+1$ then becomes:
\begin{enumerate}
\item Pick a $i$ uniformly at random in $[1, \frac{n}m]$.
\item Take $\phi_j^{k+1} = x^k \ \forall \ j \in \B_i$, and store $\frac1m
	\sum_{j\in\B_i} f_j'(\phi_j^{k+1})$ in the table.
\item Update $x^{k+1} = \prox_\gamma^h \left\{
	x^k - \gamma \left[ \frac1m \sum_{j\in\B_i} f_j'(\phi_j^{k+1})
	- \frac1m \sum_{j\in\B_i} f_j'(\phi_j^k)
	+ \frac1n \sum_{i=1}^m \sum_{j\in\B_i} f_j'(\phi_j^k) \right] \right\}.$
\end{enumerate}

Note that one can usually vectorize the computation of $\sum_{j\in\B_i}
f_j'(\phi_j^k)$. E.g. for a least-square problem $\min_x \frac12 \|Ax -
y\|_2^2$, the gradient is given by $A_{\B_i}^T A_{\B_i} x$, where $A_{\B_i}$
represents the $m$ columns of $A$ selected by the mini-batch $\B_i$. That is
where the computational advantage of the mini-batch approach comes from.

Note that mini-batches can be formed during initialization and kept intact for
the whole training. They can alternatively be reformed at the beginning of each
training epoch. While this is much more expensive, because the gradient matrix
has to be initialized again, we found no difference in performance.

\subsection{Experiments}

While the convergence rate is the same for all mini-batch sizes given the same
learning rate, larger mini-batches need a smaller learning rate to avoid
divergence.  We therefore ran experiments with various mini-batch sizes $m$;
with an optimized learning rate $\gamma$ for each. \figref{eval_saga_mb} clearly
shows that mini-batch SAGA can outperform regular SAGA in convergence time while
requiring less memory. Other simulation results as well as the problem explanation can be found in Ipython notebook file. This file contains the authors of \cite{defazio_saga_2014} implementation in Cython which is used to assess our implementation.

\begin{figure*}[ht]
	\centering
	\subfigure[Working memory to store gradients.]{
		\label{fig:memory}
		\includegraphics[height=3cm,width=7cm]{figs/memory}}
	\hspace{0pt}
	\subfigure[$R^2$ score on test set after 100s training.]{
		\label{fig:r2_score}
		\includegraphics[height=3cm,width=7cm]{figs/r2_score}}
	\\
	\subfigure[Objective w.r.t. running time.]{
		\label{fig:perf}
		\includegraphics[height=4cm,width=12cm]{figs/perf}}
	\caption{Performance evaluations of mini-batch SAGA w.r.t. various
	mini-batch sizes $m$.}
	\label{fig:eval_saga_mb}
\end{figure*}

\section{Distributed SAGA}

\begin{figure*}[ht]
	\centering
	\subfigure[First variant.]{
		\label{fig:architecture_1}
		\includegraphics[height=3cm,width=0.48\columnwidth]{figs/architecture_1}}
	\hspace{0pt}
	\subfigure[Second variant.]{
		\label{fig:architecture_2}
		\includegraphics[height=3cm,width=0.48\columnwidth]{figs/architecture_2}}
	\caption{Two variants of distributed SAGA.}
	\label{2figs-show}
\end{figure*}

\paragraph{Variant I.} A first approach, shown in \figref{architecture_1}, is to
randomly partition the $n$ data points onto $m$ machines with $n/m$ local data
points on each to parallelize the computation of \eqnref{saga}. Formally
speaking, at each epoch, we first randomly partition the data into $m$ different
sets. We then apply the SAGA algorithm presented in Section~\ref{sec1} for each
dataset on $m$ different machine. After one pass over each subset, the results
are combined by updating the gradient table and candidate solution. The updates
for epoch $e$ for each $k+1$ then become:
\begin{enumerate}
	\item Randomly partition the dataset into $m$ non-overlapping sets $R_1,
		\cdots, R_m$.
	\item For each machine $s \in \{ 1, \cdots, m \}$, pick a random sample
		$x^k(s)$ from $R_s$.
	\begin{enumerate}
		\item If $ k = 1 $ then $x^k(s) = x(e)$.
		\item Take $\phi_j^{k+1}(s) = x^k(s)$.
		\item Update $x^{k+1}(s) = \prox_\gamma^h \left\{
			x^k(s) - \gamma \left[ f_j'(\phi_j^{k+1}(s)) - f_j'(\phi_j^k(s))
			+ \frac1n \sum_{j \in R_i} f_j'(\phi_j^k(s)) \right] \right\}.$
		\item If $ k > n/m$, break.
		\item $k = k+1$.
	\end{enumerate}
	\item Merge the results with $ x(e+1) = \frac{1}{m} \sum_{s=1}^m x^k(s)$.
\end{enumerate}

\paragraph{Variant II.} A second approach, shown in \figref{architecture_2},
is to randomly pick $m$ data points and send one to each of the $m$ machines.
Each machine then computes \eqnref{saga} in parallel. All results are finally
averaged. The updates for iteration $k+1$ then become:
\begin{enumerate}
	\item For each machine $s \in \{ 1, \cdots, m \}$
	\begin{enumerate}
		\item Pick a random number $j$ in $[1, n]$.
		\item Take $\phi_j^{k+1}(s) = x^k(s)$, and store $f_j'(\phi_j^{k+1}(s))$
			in the table.
		\item Update $x^{k+1}(s) = \prox_\gamma^h \left\{
			x^k(s) - \gamma \left[ f_j'(\phi_j^{k+1}(s)) - f_j'(\phi_j^k(s))
			+ \frac1n \sum_{i=1}^n f_i'(\phi_i^k(s)) \right] \right\}.$
	\end{enumerate}
	\item Merge the results with $ x^{k+1} = \frac{1}{m} \sum_{s=1}^m
		x^{k+1}(s)$.
\end{enumerate}

\subsection{Experiments}

In this experiment, we set the $\ell_2$ regularization factor to $5\times
10^{-4}$ while we use $n=10^4$ training samples and $m=8$ different machines (or
CPU cores). \figref{distributed_perf} shows the performance of our distributed
methods. A good choice of learning rate, as for all gradient methods, is crucial
as shown in \figref{arch1_lr} and \figref{arch2_lr}. Moreover,
\figref{arch2_par} presents the required time for 1000 iterations using
different models, namely using parfor loop which is the pure distributed
implementation, for loop which is a serial implementation, and vectorized
implementation which relies on parallel implementation of linear algebra
libraries in MATLAB. The results show an heavy communication overhead for
parfor.

\begin{figure*}[ht]
	\centering
	\subfigure[Variant I: learning rate.]{
		\label{fig:arch1_lr}
		\includegraphics[width=0.31\columnwidth]{figs/arch1_lr.eps}}
	\hspace{0pt}
	\subfigure[Variant II: different parallelizations.]{
		\label{fig:arch2_par}
		\includegraphics[width=0.31\columnwidth]{figs/arch2_par.eps}}
	\hspace{0pt}
	\subfigure[Variant II: learning rate.]{
		\label{fig:arch2_lr}
		\includegraphics[width=0.31\columnwidth]{figs/arch2_lr.eps}}
	\caption{Performance measures of distributed SAGA.}
	\label{fig:distributed_perf}
\end{figure*}

\figref{conv} compares the two proposed approaches in term of convergence
rate. Variant I converges faster in running time while variant II converges
faster in the number of iterations.

\begin{figure*}[ht]
	\centering
	\subfigure[Convergence w.r.t. the number of iterations.]{
		\label{fig:conv_iterations}
		\includegraphics[width=0.31\columnwidth]{figs/conv_iterations.eps}}
	\hspace{0pt}
	\subfigure[Convergence w.r.t. running time.]{
		\label{fig:conv_time}
		\includegraphics[width=0.31\columnwidth]{figs/conv_time.eps}}
	\caption{Comparison between two distributed SAGA algorithms and regular SAGA.}
	\label{fig:conv}
\end{figure*}

\bibliography{refs}
\bibliographystyle{abbrv}

\end{document}