text:
\section{Setting up your environment for the examples}
\label{sec:environment}

The next four sections walk users through complete examples.  First,
let's compile all the instrumentation handlers that come with SASSI,
including the ones the next few sections cover.  First, navigate to
the instrumentation library directory:
\begin{lstlisting}[style=BashInputStyle]
cd $SASSI_REPO/instlibs
\end{lstlisting}
Next, we need to edit the file \texttt{env.mk}.  There are four
environment variables we need to set:
\begin{itemize}
\item \texttt{CUDA\_HOME}: This is the location of your CUDA 7 root.
\item \texttt{SASSI\_HOME}: This is the location of your SASSI
  installation root (not the repository root).
\item \texttt{CCBIN}: The location of the C++-11 compiler you want to
  use.
\item \texttt{GENCODE}: What GPUs you want to compile your
  instrumentation libraries for. \hl{Remember you must specify a
    \emph{real} architecture, not a virtual one.}
\end{itemize}

After editing the file, you \emph{should} be able to simply invoke
\texttt{make} (in \texttt{\$SASSI\_REPO/instlibs}), which will compile
the instrumentation libraries and install them in
\texttt{\$SASSI\_REPO/instlibs/lib}. \hl{For users that are targeting
  Fermi cards (sm\_20, sm\_21), it is very important to note that not
  all of the instrumentation libraries will compile.  Most of the
  instrumentation libraries use features that are only available in
  3.0+ architectures.  There is a special make target, \texttt{make
    fermi-only}, that will only make the instrumentation libraries
  that will run on Fermi.}

The examples in the next several sections all rely heavily on NVIDIA's
CUPTI library, so let's add it to our \texttt{LD\_LIBRARY\_PATH}:
\begin{lstlisting}[style=BashInputStyle]
export LD_LIBRARY_PATH=$SASSI_HOME/extras/CUPTI/lib64:$LD_LIBRARY_PATH
\end{lstlisting}

ext: tex


text:
%% tb94cho.ltx
%% Copyright 2010 Jin-Hwan CHO
%
% This work may be distributed and/or modified under the
% conditions of the LaTeX Project Public License, either version 1.3
% of this license or (at your option) any later version.
% The latest version of this license is in
%   http://www.latex-project.org/lppl.txt
% and version 1.3 or later is part of all distributions of LaTeX
% version 2005/12/01 or later.
%
% This work has the LPPL maintenance status `maintained'.
%
% The Current Maintainer of this work is Jin-Hwan CHO.

\documentclass[final]{ltugboat}

\usepackage{graphicx}
\usepackage{url}
%\usepackage{picins}
\usepackage{microtype}

\def\CFF{\acro{CFF}}
\def\CID{\acro{CID}}
\def\CJK{\acro{CJK}}
\def\DTL{\acro{DTL}}
\def\DVIasm{\acro{DVI}asm}
\def\DVItype{\acro{DVI}type}
\def\DPS{\acro{DVIPS}}
\def\DPM{\acro{DVI\-PDFM}}
\def\DPMx{\acro{DVI\-PDFM}($x$)}
\let\DPX\DVIPDFMx
\def\pdfmark{pdfmark}
\def\GS{Ghostscript}
\def\EPS{\acro{EPS}}
\def\pdfTeX{pdf\/\TeX}
\def\LuaTeX{Lua\TeX}
\def\pTeX{p\kern-0.05em\TeX}
\def\XObject{\acro{XO}bject}
\def\fafter{1.5pt}

\let\note=\footnote
\def\ctanloc#1{\url{http://mirror.ctan.org/#1}}
\setlength{\fboxsep}{1.5pt}

%\divide\abovecaptionskip by 2

% don't go to a float page so soon:
%\renewcommand{\dbltopfraction}{.99}
%\renewcommand{\dblfloatpagefraction}{.8}

\title{\DVI\ specials for \PDF\ generation}
\author{Jin-Hwan Cho}
\address{Department of Mathematics \\ The University of Suwon \\ Republic of Korea}
\netaddress{chofchof (at) ktug dot or dot kr}

\begin{document}
\sectitle{Software \& Tools}
\maketitle

\begin{abstract}%
\acro{DVIPDFM}($x$) manages various \PDF\ effects by means of \DVI\ specials.
Appropriate documentation of \DVI\ specials, however, is not easy to find, and exact functionality is not simple to catch without reading the source code of \DVI\ drivers.
This paper deals with the \DVI\ specials defined in \acro{DVIPDFM}($x$) that are mainly used for \PDF\ generation.
We discuss the features of those specials with some examples, many of which are not documented elsewhere.
\end{abstract}

\section{Introduction}

\DVI, the output file format of D.~E.~Knuth's \TeX, is not widely used at present compared with \PDF, the output format of \pdfTeX.
It is rather old\note{\DVI\ was designed by David R.~Fuchs in 1979.} and obsolete, but it has powerful aspects nonetheless: \emph{simplicity} and \emph{compactness}.

These aspects make it possible to manipulate \DVI\ files in an easy and fast way.
Many \DVI\ utilities were developed to convert the \DVI\ format to other file formats including \PS\ and \PDF.
It is also possible to edit \DVI\ files directly by the use of \DVIasm~\cite{Cho07,Cho08,DVIasm}.

Twenty years ago, at the time \PS\ dominated the printing world, nobody expected a new format would replace \PS.
\PDF\ is not eternal either.
In future, when a new format surpassing \PDF\ appears, \DVI\ will be the first format in the \TeX\ world that can be converted to the new format.
Notice that \LuaTeX, considered to be the next generation of \pdfTeX, still supports the \DVI\ format.

There are two popular ways to convert \DVI\ to \PDF.
The first one is a two-way conversion, from \DVI\ to \PS\ with \DPS, and then from \PS\ to \PDF\ with a distiller.
Adobe Acrobat Distiller is the oldest commercial program, and \GS\ is the most popular distiller in the \TeX\ world. \MacOSX\ also has its own distiller.

Adobe designed the \pdfmark\ operator~\cite{pdfmark} for its distiller to support \PDF\ features that are not expressible using the standard \PS\ operators.
The \pdfmark\ operator is given in the \TeX\ source by means of a \DVI\ special command.
Note that it is not \DPS\ but a distiller that processes the \pdfmark\ operator.

Mark A.~Wicks' \DPM~\cite{DVIPDFM} introduced the other way of converting \DVI\ directly to \PDF.
He also designed new \DVI\ specials based on the \pdfmark\ operator to support various \PDF\ features.
The new specials, however, lacked some functionality in practical use so that not many \PDF\ features could be obtained compared with \pdfTeX.

One of the main goal of \DPX, an extension of \DPM\ that grew out of the \CJK\note{Chinese, Japanese, and Korean.} support, was to provide as many \PDF\ features as \pdfTeX~\cite{Cho03}.
\DPX\ extended the functionality of some special commands of \DPM, and designed new special commands having a similar functionality of \pdfTeX's own primitives.
Furthermore, \DPX\ has several powerful features not available in \DPM.
	\begin{itemize}
	\item Support 16-bit character sets (\CJK\ encodings and Unicode) with \CID-keyed font technology.
	\item Support various font formats including OpenType, TrueType, etc.
	\item Use \CFF\ font format for embedded Type1 \PS\ fonts so that the size of the \PDF\ output is quite small compared with \pdfTeX's output.
	\item Support extended \TeX\ engines, e.g., Omega, Japanese \pTeX, \XeTeX\ (via \acro{XDVIPDFMX}).\note{Upcoming version of \DPX\ will support the \DVI\ output generated by \LuaTeX.}
	\end{itemize}

The \acro{TODO} list of \DPX\ had contained one outstanding item for a long time: supporting Till Tantau's beamer package~\cite{beamer}, that is widely used for \PDF\ presentation.
In fact, this package does not handle \DVI\ specials in a direct way.
Instead, the graphics part comes from the same author's \PGF\ package~\cite{PGF}, and the other \PDF\ effects come from the hyperref package~\cite{hyperref}.

\DPX\ has supported full functionality of the \PGF\ package since June 2008.\note{The \DPX\ driver that works with the \PGF\ package included in \TeX\ Live 2008 can be downloaded from \url{http://project.ktug.or.kr/dvipdfmx/contrib/generic/}.}
Nonetheless, the navigation buttons usually shown in the lower right corner of the presentation still did not work, although they were displayed correctly.
The source code\note{\raggedright \ctanloc{macros/latex/contrib/beamer/base/beamerbasenavigation.sty}} implementing the buttons was

\begin{verbatim}[\small]
\def\beamer@linkspace#1{\vbox to7.5pt{}\kern#1}
\end{verbatim}

The code above generates an \emph{empty} box that will be surrounded by the two special commands, `\texttt{pdf:bann}' (before) and `\texttt{pdf:eann}' (after).
Unfortunately, neither \DPM\ nor \DPX\ construct any annotation in the case of an empty box.
Another special command `\texttt{pdf:ann}' must be used instead for this purpose.
That was the exact reason why the navigation buttons did not work.

Why did the author of the beamer package make such a mistake?
As a matter of fact, it was not his fault because no statement could be found about that functionality in the manual of \DPM~\cite{DVIPDFM}.
This unhappy story led to this paper.

The author gave a presentation~\cite{Cho05} at \tug\ 2005, in which the different behaviors of \DVI\ specials of \DPS, \DPM, and \DPX\ were discussed.
\DVI\ specials for \PDF\ generation, however, were not fully discussed at that time.
The main objective of this paper is to bridge this gap.

We will discuss in the following sections the features of \DVI\ specials defined in \DPM\ for \PDF\ generation, and the extended features given by \DPX.
The author hopes this paper would be useful for package writers who are finding appropriate information on \DVI\ specials.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Named PDF objects}

There are two kinds of named objects, built-in and user-defined \PDF\ objects.

\subsection{Built-in named objects}

Built-in objects defined in \DPMx{} are listed in Table~\ref{Table1}. We refer to~\cite[p.~12]{pdfmark} and~\cite[p.~5]{DVIPDFM} for \pdfmark\ and \DPM\ built-in objects, respectively.
Notice that it is not allowed to modify the contents of the last five built-in objects in Table~\ref{Table1}.

\begin{table}[h]
\begin{tabular}{|l|p{1.95in}|} \hline
\texttt{@catalog} & catalog dictionary~\cite[p.~139]{PDFReference} \\
\texttt{@docinfo} & (\DPX\ only) document\newline information dictionary \cite[p.~844]{PDFReference} \\
\texttt{@names} & name dictionary~\cite[p.~150]{PDFReference} \\
\texttt{@pages} & root page tree node \cite[p.~143]{PDFReference} \\
\texttt{@resources} & resource dictionary of current\newline page \cite[p.~154]{PDFReference} \\
\texttt{@thispage} & current page object \cite[p.~145]{PDFReference} \\\hline
\texttt{@prevpage} & reference only \\
\texttt{@nextpage} & reference only \\
\texttt{@page$n$} & reference only \\
\texttt{@xpos} & reference only \\
\texttt{@ypos} & reference only \\
\hline
\end{tabular}
\caption{Built-in objects defined in \DPMx{}}
\label{Table1}
\end{table}

\subsection{User-defined named objects}

Two special commands are provided by \DPMx{} for user-defined objects.
One is to define a named object, and the other is to add content to the previously defined object.

\begin{itemize}
\item\fbox{\ttfamily pdf:obj @name PDFobject} \ creates a named object that can be referenced later by `\texttt{@name}'.
\end{itemize}

\noindent
All possible object types for `\texttt{PDFobject}' are listed in Table~\ref{Table2}.
In the case of indirect objects, the object number must be given explicitly, so that this feature is rarely used, especially to specify the objects in a different \PDF\ file.

\begin{table}[h]
\begin{tabular}{|l|p{2.1in}|} \hline
boolean & \texttt{true}, \texttt{false} \\
numeric & \texttt{123}, \texttt{34.5}, \texttt{-.002} \\
string & \texttt{(This is a string)}, \texttt{<901FA3>} \\
name & \texttt{/Name1}, \texttt{/.notdef} \\
array & \texttt{[3.14 false (Ralph) /Name1]} \\
dictionary & \texttt{<</Key1 (Value) /Key2 3.14>>} \\
null & \texttt{null} \\\hline
indirect & \texttt{12 0 R} \\
stream & \texttt{stream ... endstream} \\
\hline
\end{tabular}
\caption{\PDF\ object types~\cite[p.~51]{PDFReference}}
\label{Table2}
\end{table}

It is not simple to construct a stream object with the special command `\texttt{pdf:obj}' because
the length of the stream object must be specified explicitly, which is quite bothersome.
Imagine that you are trying to construct a stream object whose source comes from a file.
Is it possible with this special command?
Moreover, any stream object requires the keyword `\texttt{stream}' followed by an end-of-line marker.\note{%
An end-of-line marker consists of either a carriage return (\texttt{0x0d}) and a line feed (\texttt{0x0a}) or just a line feed, and not by a carriage return alone~\cite[pp.~60--61]{PDFReference}.}

\DPX, therefore, provides new special commands for stream objects.

\begin{itemize}
\item\fbox{\ttfamily pdf:stream @name (string) <<dict>>} \\[\fafter]
constructs a stream object the source of which comes from the string object `\texttt{(string)}'.
The stream dictionary `\texttt{<<dict>>}' is optional, and the dictionary entry `\texttt{/Length}' is created automatically.
\end{itemize}

\noindent
The following two special commands, for instance, construct the same stream object.
The stream data of the second object is represented in the \ASCII\ base-85 encoding.~\cite[p.~70]{PDFReference}

\begin{verbatim}[\small]
\special{pdf:stream @name (xxxxxxxx)}
\special{pdf:stream @name (G^+IXG^+IX)
         <</Filter/ASCII85Decode>>}
\end{verbatim}

\begin{itemize}
\item\fbox{\ttfamily pdf:fstream @name (filename) <<dict>>} \\[\fafter]
constructs a stream object in the same way as `\texttt{pdf:stream}', but the source of stream data comes from a file `\texttt{filename}'.
\end{itemize}

\noindent
The following example shows how to include a source \TeX\ file inside the output \PDF\ file. (See~\cite[p.~637]{PDFReference} for more details on the file attachment annotation.)

\begin{verbatim}[\small]
\special{pdf:fstream @myfile (mytest.tex)}
\special{pdf:ann bbox 0 0 10 10 <<
  /Subtype /FileAttachment /FS <<
    /Type /Filespec /F (mytest.tex)
       /EF << /F @myfile >> >>
  /Name /PushPin >>}
\end{verbatim}

\subsection{Adding content to named objects}

We describe the special command for adding content to named objects. The type of the named object must be either array or dictionary.

\begin{itemize}
\item\fbox{\ttfamily pdf:put @arrayobj object$_1$ $\ldots$ object$_n$} \\[\fafter]
appends the $n$ objects at the end of the array object `\texttt{@arrayobj}'.
\item\fbox{\ttfamily pdf:put @dictobj <<dict>>} \ merges the dictionary object `\texttt{<<dict>>}' into `\texttt{@dictobj}'. If both the dictionaries have a common key, the old value in `\texttt{@dictobj}' will be replaced by the new value in `\texttt{<<dict>>}'.
\end{itemize}

\noindent
In the following example, the value of the key `\texttt{/X}' in the dictionary object `\texttt{@name}' is `\texttt{@Moon2}'.
(See~\cite[p.~15]{pdfmark} for corresponding \pdfmark\ operators.)

\begin{verbatim}[\small]
\special{pdf:put @Moon1
         [ (Earth to Moon) 238855 /mies ]}
\special{pdf:obj @Moon2 []}
\special{pdf:put @Moon2 (Moon to Earth)}
\special{pdf:put @Moon2 238855}
\special{pdf:put @Moon2 /miles}
\special{pdf:obj @name <<>>}
\special{pdf:put @name << /X @Moon1 >>}
\special{pdf:put @name << /X @Moon2 >>}
\end{verbatim}

Note that \DPM\ does not allow adding content to a stream dictionary object, but \DPX\ does.

\begin{itemize}
\item\fbox{\ttfamily pdf:put @streamobj <<dict>>} \ \ merges the dictionary object `\texttt{<<dict>>}' into the stream dictionary of `\texttt{@streamobj}'. The dictionary entries, `\texttt{/Length}' and `\texttt{/Filter}', in the object `\texttt{<<dict>>}' will be ignored.
\end{itemize}

Finally, \DPMx{} provides the special command
\fbox{\ttfamily pdf:close @name} to prevent further modifying the content of `\texttt{@name}'. After closing the named object, it can only be referenced.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Annotations}

An annotation is considered as an object with a location on a page.
The type of the object is given by the value of the key `\texttt{/Subtype}', for instance, `\texttt{/Text}', `\texttt{/Link}', `\texttt{/Sound}', `\texttt{/Movie}', etc.
(See~\cite[p.~615]{PDFReference} for the list of all annotation types.)
The location is given by an array object associated to the key `\texttt{/Rect}'.
\DPMx{} provides the following special command for annotations.

\begin{itemize}
\item\fbox{\hbadness=10000
\parbox{.43\textwidth}{\ttfamily pdf:ann @name width [length] height [length] depth [length] <<dict>>}}
\par\vspace{\fafter}\noindent
The annotation dictionary is given by `\texttt{<<dict>>}' and the location relative to the current position is given by the three dimension parameters, `\texttt{width}', `\texttt{height}', and `\texttt{depth}'.
\end{itemize}

\noindent
It is not possible to specify the location in an absolute way.
Any value of the key `\texttt{/Rect}' in the annotation dictionary `\texttt{<<dict>>}' will be ignored if found.
It is not allowed to modify the annotation dictionary with `\texttt{pdf:put}' command, so `\texttt{@name}' must be used as a reference.

Note that \DPX\ allows the `\texttt{bp}' unit in the dimension parameters, but \DPM\ does not.
Moreover, \DPX\ supports the following form.

\begin{itemize}
\item\fbox{\hbadness=10000
\parbox{.425\textwidth}{\ttfamily pdf:ann @name bbox [ulx] [uly] [lrx] [lry] <<dict>>}}
\par\vspace{\fafter}\noindent
The relative location is given by the bounding box consisting of four numbers in `\texttt{bp}' units.
\end{itemize}

\noindent
The following example shows a movie annotation that enables us to run the movie file `\texttt{mymovie.avi}' inside a \PDF\ viewer program.

\begin{verbatim}
\special{pdf:ann bbox 0 0 360 180 <<
  /Subtype /Movie /Border [1 0 0]
  /T (My Movie) /Movie <<
    /F (mymovie.avi) /Aspect [720 360]
    /Poster true >>
  /A << /ShowControls false >> >>}
\end{verbatim}

\DPMx{} provides other special commands for \emph{breakable} annotations, e.g., an annotation broken over several lines or several pages.

\begin{itemize}
\item\fbox{\ttfamily pdf:bann <<dict>>} \ begins a breakable annotation.
Object name is not allowed for this command.
\item\fbox{\ttfamily pdf:eann} \ terminates the previous breakable annotation.
\end{itemize}

\noindent
These specials are mainly used for `\texttt{/Link}' annotation as the following example shows.

\begin{verbatim}[\small]
\special{pdf:bann << /Subtype /Link
  /BS << /Type /Border /W 0.5 /S /S >>
  /A << /S /URI
    /URI (http://www.tug.org) >> >>}%
http://www.tug.org%
\special{pdf:eann}
\end{verbatim}

\noindent
\emph{Warning:} No annotation will be constructed if the content between `\texttt{pdf:bann}' and `\texttt{pdf:eann}' is an empty box.  For example:

\begin{verbatim}[\small]
\special{pdf:bann << /Subtype /Link ... >>}
\vbox to 7.5pt{}\kern 10pt
\sepcial{pdf:eann}
\end{verbatim}

Annotations constructed by \DPMx{} may happen to be slightly bigger than the expected size. This occurs when the annotation grow size is positive; this value is specified in the configuration file. To avoid this effect, either modify the configuration file or give `\texttt{-g 0}' on the command line when running \DPMx{}.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Outlines (or bookmarks)}

The document outline consists of a tree-structured hierarchy of outline items (sometimes called bookmarks) for which \DPMx{} provides the following special command.

\begin{itemize}
\item\fbox{\ttfamily pdf:out $n$ <<dict>>} \ adds an outline item to the document. The integer parameter $n$ represents the level of the outline entry (beginning with 1), and `\texttt{<<dict>>}' represents the outline item dictionary~\cite[p.~585]{PDFReference}.
\end{itemize}

Note that all the outline items generated by \DPM\ are closed.\note{The sign of the value of the key `\texttt{/Count}' in the outline item dictionary determines whether the item is open or closed.~\cite[p.~586]{PDFReference}}
The `\texttt{bookmarksopen=true}' option of the hyperref package does not work if the \PDF\ output is generated by \DPM.

\begin{verbatim}[\small]
\usepackage[
  dvipdfm,bookmarks=true,bookmarksopen=true
]{hyperref}
\end{verbatim}

\DPX\ provides two solutions for this problem.
The first one is to specify the option `\texttt{-O $n$}' when running \DPX.
Up to level $n$, the outline entries will be open. The second, and complete, solution is to use this extended special command:

\begin{itemize}
\item\fbox{\ttfamily pdf:out [-] $n$ <<dict>>} \ The symbol `\texttt{[-]}' indicates that the outline item will be closed. On the other hand, `\texttt{[]}' without the minus sign indicates that the outline item will be open.
\end{itemize}

The hyperref package provides a new option `\texttt{dvipdfmx-outline-open}' that uses the extended command above. This option enables us to control the open level given by `\texttt{bookmarksopenlevel}'.

\begin{verbatim}[\small]
\usepackage[%
  dvipdfmx,bookmarks=true,
  bookmarksopen=true,
  bookmarksopenlevel=1,
  dvipdfmx-outline-open
]{hyperref}
\end{verbatim}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{External objects (or XObjects)}

\DPMx{} supports two types of \emph{external objects},\note{%
``A graphics object whose contents are defined by a self-contained content stream, separate from the content stream in which it is used.''~\cite[p.~332]{PDFReference}
} an image \XObject{} and a form \XObject.

\begin{itemize}
\item\fbox{\hbadness=10000
\parbox{.42\textwidth}{\ttfamily pdf:image @name width [length] height [length] depth [length] (imagefile)}}
\par\vspace{\fafter}\noindent
defines an image \XObject\ the source of which comes from the file `\texttt{imagefile}'. See~\cite[p.~216]{Cho07} for complete syntax provided by \DPX.
\item\fbox{\hbadness=10000
\parbox{.42\textwidth}{\ttfamily pdf:bxobj @name width [length] height [length] depth [length]}}
\par\vspace{\fafter}\noindent
begins the definition of a form \XObject.
As with the command `\texttt{pdf:add}', \DPX\ allows bounding box `\texttt{bbox [ulx] [uly] [lrx] [lry]}' for dimension parameters.
\item\fbox{\ttfamily pdf:exobj} \ ends the previous form \XObject\ definition.
\item\fbox{\ttfamily pdf:uxobj @name} \ displays the image \XObject\ or the form \XObject\ previously defined and associated with `\texttt{@name}'.
\DPM$x$ allows dimension parameters (same as `\texttt{pdf:image}') after `\texttt{@name}'.
\end{itemize}

\noindent
Typical examples showing how to use image \XObject{}s and form \XObject{}s can be found in~\cite[pp.~15--16]{Cho05}.

\begin{figure}[h]
\centering\includegraphics{transparencygroup.pdf}
\caption{Two form \XObject{}s with opacity 0.5; the right one is a group \XObject.}
\label{Figure1}
\end{figure}

\DPX\ extended the command `\texttt{pdf:eann}' to support a group \XObject.\note{``A special type of form \XObject\ that can be used to group graphical elements together as a unit for various purposes.'' \cite[p.~360]{PDFReference}}
Figure~\ref{Figure1} shows the difference between a normal \XObject\ and a group \XObject.

\begin{itemize}
\item\fbox{\ttfamily pdf:exobj <<dict>>} \ merges the dictionary object `\texttt{<<dict>>}' into the type1 form dictionary~\cite[p.~358]{PDFReference} of the previous form \XObject\ and then close the \XObject.
\end{itemize}

\noindent
The following code draws the right image in Figure~\ref{Figure1}.

\begin{verbatim}[\small]
\special{pdf:bxobj @group bbox 0 0 50 50}
\special{pdf:code
    15 w 0 0 m 50 50 l S 50 0 m 0 50 l S}
\special{pdf:exobj << /Group
   << /S /Transparency >> >>}
\special{pdf:obj @extgstate
   << /CA0.5 <</CA 0.5>> /ca0.5 <</ca 0.5>> >>}
\special{pdf:put @resources
   << /ExtGState @extgstate >>}
\special{pdf:code /CA0.5 gs /ca0.5 gs}
\special{pdf:uxobj @group}
\end{verbatim}

\noindent We get the left image if \verb+\special{pdf:exobj}+ is used instead of the 4th and the 5th line.

\section{Raw PDF Operators}

This final section deals with writing raw \PDF\ operators in the output.
\DPM\ provides a special command for this feature.

\begin{itemize}
\item\fbox{\ttfamily pdf:content Operators} \vadjust{\vskip2pt} adds the list of operators ``\texttt{Operators}'' to the current page at the current location.
The operator `\texttt{q}', saving the current graphics state, followed by a transformation matrix moving to the current location will be attached to the beginning of the list, and the operator `\texttt{Q}' restoring the saved graphics state at the end of the list.
\end{itemize}

For instance, the special command

\begin{verbatim}
\special{pdf:content 10 w 0 0 m 50 50 l S}
\end{verbatim}

\noindent
inserts the following list of operators in the output.

\smallskip\noindent
{\fontsize{9pt}{11pt}\selectfont
%\begin{verbatim}
\ttfamily\ldots\,%
\fbox{\strut q}\,\fbox{\strut 1 0 0 1 $x$ $y$ cm}\,%
10 w 0 0 m 50 50 l S
\fbox{\strut Q}\,%
\ldots
%\end{verbatim}
}

We sometimes need to insert \PDF\ operators without additional graphics state operators.
The author of the \PGF\ package devised a trick:

{\hfuzz=5pt
\begin{verbatim}
\special{pdf:content Q ... Operators ... q}
\end{verbatim}
}

\noindent
The first operator `\texttt{Q}' and the last operator `\texttt{q}' nullify the effects of graphics state operators that are attached.

\DPX\ provides a new special command instead of the trick above.

\begin{itemize}
\item\fbox{\ttfamily pdf:literal direct Operators}\note{%
The idea of `\texttt{pdf:literal direct}' came from the primitive `\cs{pdfliteral direct}' of \pdfTeX.} \ or simply\\[\fafter]
\fbox{\ttfamily pdf:code Operators} \ plays the same role as\\[\fafter]
`\texttt{pdf:content}, but no graphics state operator and no
transformation matrix will be added.
\end{itemize}

\begin{figure}[h]
\centering\includegraphics{bcontent.pdf}
\caption{The location of `23' in the left image varies according to the location of 1 in the current page.}
\label{Figure2}
\end{figure}

Consider the following code, labelled Listing~\ref{Code1}. Which image in Figure~\ref{Figure2} does this code generate?

\renewcommand{\tablename}{Listing}
\setcounter{table}{0}
\begin{table}[h]
%{
\hfuzz=5pt
\fontsize{9pt}{11pt}\selectfont
\begin{verbatim}
\def\bpic{\special{pdf:content q}}
\def\epic{\special{pdf:content Q}}
\def\myop#1{\special{pdf:content Q #1 q}}
1\bpic2\myop{.5 G 10 w 0 0 m 100 100 l S}3\epic4
\end{verbatim}
%}
\caption{Which image in Figure~\ref{Figure2} is the result of this code, produced by \DPM($x$)?}
\label{Code1}
\end{table}

The macro \cs{bpic} in Listing~\ref{Code1} nullifies the effect of the operator `\texttt{Q}' that will be attached after `\texttt{q}', and the macro \cs{epic} nullifies the effect of the list `\texttt{q 1 0 0 1 $x$ $y$ cm}' that will be attached before `\texttt{Q}'.

Most people may choose the right-hand image in Figure~\ref{Figure2} as the result of Listing~\ref{Code1}, if they remember the fact that special commands are considered nothing by \TeX. However, the answer is the left-hand image.
The reason is that the transformation matrix in the macro \cs{bpic} still has an effect on the characters `2' and `3'. The effect will be nullified by the macro \cs{epic}.

To produce the right-hand image, \DPX\ provides the following new special commands.

\begin{itemize}
\item\fbox{\ttfamily pdf:bcontent} \ starts a block that works in the same way as `\texttt{pdf:content}' except that all text between this command and `\texttt{pdf:econtent}' will be placed in the right position.
\item\fbox{\ttfamily pdf:econtent} \ ends the current block.
\end{itemize}

\noindent
Moreover, `\texttt{pdf:bcontent}' and `\texttt{pdf:econtent}' can be nested.

Finally, we can get the right-hand image in Figure~\ref{Figure2} as the result of Listing~\ref{Code2} following, produced by \DPX.

\begin{table}[h]
%{
\hfuzz=5pt
\fontsize{9pt}{11pt}\selectfont
\begin{verbatim}
\def\bpic{\special{pdf:bcontent}}
\def\epic{\special{pdf:econtent}}
\def\myop#1{\special{pdf:code #1}}
1\bpic2\myop{.5 G 10 w 0 0 m 100 100 l S}3\epic4
\end{verbatim}
%}
\caption{The right-hand image in Figure~\ref{Figure2} is the result of this example produced by \DPX.}
\label{Code2}
\end{table}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\SetBibJustification\raggedright
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{thebibliography}{99}

\bibitem{PDFReference} Adobe Systems, Inc., \emph{\PDF\ Reference}, \nth{6} edition (Version 1.7, November 2006).
  \url{http://www.adobe.com/devnet/acrobat/pdfs/pdf_reference_1-7.pdf}.

\bibitem{pdfmark} Adobe Systems, Inc., \emph{\pdfmark\ Reference}
(Version 8.0, November 2006).
  \url{http://www.adobe.com/devnet/acrobat/pdfs/pdfmark_reference.pdf}.

\bibitem{Cho03}
Jin-Hwan Cho, \emph{\DPX, an extension of \DPM},
  \tug\ 2003. Hawaii, United States.
  \url{http://project.ktug.or.kr/dvipdfmx/doc/tug2003.pdf}.

\bibitem{Cho05}
Jin-Hwan Cho, \emph{Practical Use of Special Commands in \DPX},
  \tug\ 2005, International Typesetting Conference. Wuhan, China.
  \url{http://project.ktug.or.kr/dvipdfmx/doc/tug2005.pdf}.

\bibitem{Cho07}
Jin-Hwan Cho, \emph{Hacking \DVI\ files: Birth of \DVIasm}, The Prac\TeX\ Journal (2007), no.~1, and TUGboat 28:2, 2007, 210--217.
  \url{http://tug.org/TUGboat/Articles/tb28-2/tb89cho.pdf}.

\bibitem{Cho08}
Jin-Hwan Cho, \emph{Handling Two-Byte Characters with \DVIasm}, The Asian Journal of \TeX\ \textbf{2} (2008), no.~1, 63--68.
  \url{http://ajt.ktug.kr/assets/2008/5/1/0201cho.pdf}.

\bibitem{DVIasm}
Jin-Hwan Cho, \emph{The \DVIasm\ Python script}.
  \ctanloc{dviware/dviasm/}.

\bibitem{hyperref}
Heiko Oberdiek, \emph{The hyperref package} (Version 6.78f, August 2008).
  \ctanloc{macros/latex/contrib/hyperref/}

\bibitem{beamer}
Till Tantau, \emph{The beamer package} (Version 3.07, March 2007).
  \ctanloc{macros/latex/contrib/beamer/}.

\newpage
\bibitem{PGF}
Till Tantau, \emph{\PGF, A Portable Graphics Format for \TeX} (Version 2.00, February 2008).
  \ctanloc{graphics/pgf/}.

\bibitem{DVIPDFM} Mark A. Wicks, \emph{\DPM\ User's Manual}
(Version 0.12.4, September 1999).
  \url{http://gaspra.kettering.edu/dvipdfm/dvipdfm-0.12.4.pdf}.

\end{thebibliography}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\medskip
\makesignature
\end{document}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


text:
\chapter{Concept and Design}
\label{cha:conceptanddesign}

DC3 dashboard has 3 different types of personas - Company, Customer and Postman. Hence we had to design the system differently for each user persona. Our front end application is a Single Page Application (SPA) using react JS. Our back-end is developed by using Node JS leveraging Express framework.

\section{Architecture}
DC3 follows a modular approach for the whole system. As shown in the bigger picture, entry point for the system is social login, Google in this case. we are using passportJS which can be used to integrate other social strategies e.g. GitHub, Facebook as well. Furthermore, passport does provide local strategy as well where we can configure local database as well for authentication and authorization. This feature would be useful when we different vendors does deploy their own instances of the diLLas service and want to authorize the existing customer base from their own system. we have detailed overview for google authorization explained later as well

\begin{figure}[!ht]
	\centering
	\includegraphics[width=1 \textwidth]{images/bigger_picture.png}\\
	\caption{System Architecture(abstract view)}
	\label{fig:System Architecture(abstract view)}
\end{figure}

Once user is logged-in, for example from browser, an access-token is stored into the local session storage for being used on the front end SPA (Single Page Application) react app.  This token is used for further communication between front-end and back-end. It contains user profile and authorization info. This info is leveraged to protect the different endpoints on the server side and provide related data based on the user type. For example, when a customer hits the /packages endpoint he will be able to see his own packages only but when a company user hits the same endpoint, he will get all the company level packages in the response.

\section{Authentication and Authorization with Google}

Authentication is a vital part of the project and most real world applications need authentication and authorization. While authentication identifies some entity as a valid user, authorization defines the actions that the user is allowed to perform, based on his/her roles and rights. There are many solutions to provide for authentication or authorization in an application and we had two major choices,

\begin{itemize}
\item First one was to keep user state management on Redux.
\item Second was to use a Facebook or a Google Authentication integration with our application.
\end{itemize}

We chose to go with the second choice as it was a new learning for the team to integrate it with our application using the PassportJS framework, it also reduces the burden of the users to register themselves rather directly sign in with their Google accounts and more importantly because it provides back-end services to securely authenticate users, paired with easy-to-use client SDKs. It can authenticate users using passwords and federated identity provider credentials.

In our application, once the user clicks on the Google authenticate button,it directs the user to Google's OAuth 2.0 server, which requests access to the user's meta data from the Google drive with a read only scope. Further after granting or denying the access to the user, is then redirected to the original page, which pareses the access token from the string. The page then uses this access token to make  a simple API request which calls the Drive API's to retrieve the information about the authorized user's Google account. If this request is successful then the API response is logged in the browser.
For the first time user's we check our local database to determine the existence and add the user to our database if the user name does not exist and fill in the vital information using the above fetched information from the authorized user's Google account. We have achieved the same with the help of the PassportJS framework where it provides us local strategy to configure our local database for such authentications. Also if the user name exists before hand, we validate the token from the server side with the OAuth2.0 provider and once validated, a JSON Web Token (JWT)  is produced to securely provide authorization to the front end.
We use a main component in our database table "Persons" that is "PersonType" component which determines the role given to a user.Based on this value we determine if the user is either a customer,postman or a company representative. The role with the lowest features is the role of a user, which is the value provided by default to the user on first time log in and henceforth the company role has  authorization to upgrade the user to a postman or a company representative. Initial company role setup is done by the admin. The below figure provides a overview of the functioning of the Google authentication and Authorization based on role integrated to our DC3 application.

\begin{figure}[!ht]
	\centering
	\includegraphics[width=0.5\textwidth]{images/GoogleAuth.jpeg}\\
	\caption{Authentication \& Authorization}
	\label{fig:Authentication and Authorization}
\end{figure}

\section{Database Design}
DC3 database has 8 tables. Order, Person, Order History and Order sensors are the major tables while others play an important role as well.  Designs majorly circulate around Orders table. We have normalized the database to avoid storing redundant data e.g. Order and Sensors had many to many relationship so we divided it and created another table, OrderSensors. Let’s understand the philosophy behind each table

\subsection{Company}
The company table is persisting the information about all the companies. It stores the company name and a brief description of the company.

\begin{table}[!ht]
	%\small
	\centering
	\begin{tabular}{ |l|l|l| }
		\hline
		Id & Int - auto increment & Unique company ID \\
		\hline
		Name & varchar & Company Name \\
		\hline
		Description & varchar & Brief company description \\
		\hline
	\end{tabular}
	\caption{Company table}
\end{table}

\subsection{Address}
Address table is maintaining all kind of address across the whole system, be it order adree or customer home address. Hence it has relationship with Order and Person. Order table has two address Ids, each for pick and delivery address of the order

\begin{table}[!ht]
	%\small
	\centering
	\begin{tabular}{ |l|l|l| }
		\hline
		AddressId  & Int - Autoincrement & \\
		\hline
		StreetAddress  & varchar & \\
		\hline
		City  & varchar &\\
		\hline
		Country  & varchar &\\
		\hline
		PostCode  & int &\\
		\hline
	\end{tabular}
	\caption{Address table}
\end{table}

\subsection{Sensor}
The sensor table is a repository of unique sensors we have available in the system. It will store the names, and different possible thresholds a specific sensors has. It was designed in a generic way to store the different sensors in the same table.

\begin{table}[!ht]
	\small
	\centering
	\begin{tabular}{ |l|l|l| }
		\hline
		Id  & Int - Autoincrement  & \\
		\hline
		Name  & varchar & \\
		\hline
		MinValue & varchar & Minimum possible reading for the sensor  \\
		\hline
		MaxValue & varchar & Maximum possible reading for the sensor\\
		\hline
		DisplayUnit  & varchar & \\
		\hline
	\end{tabular}
	\caption{Sensor table}
\end{table}

\subsection{Person}
The Person table is storing various kinds of user information. It stores personal information for the company, customer and postman. Additionally, it maintains the social login values for the user. Once a user signs up, it defaults to a customer but admin or company user can change his role to postman or admin (company) user.

\begin{table}[!ht]
    \begin{center}
    \begin{tabular}{ |l|l|l| }
    \hline
    Id & Int - auto increment & Unique company ID \\
    \hline
    FullName & varchar & \\
    \hline
    Email  & varchar & \\
     \hline
    Password & varchar & Minimum possible reading for the sensor \\
     \hline
    DateOfBirth & varchar & Maximum possible reading for the sensor \\
     \hline
    PersonType & varchar & Person type e.g. customer, postman or company \\
    \hline
    PersonRole & int & Stores person role or associated company id \\
    \hline
    GoogleProviderId & varchar & Google user-id \\
    \hline
    GoogleAccessToken & varchar & Logged-in user access token\\
    \hline
    \end{tabular}
    \end{center}
    \caption{Person table}
\end{table}

\subsection{Orders}
Orders table is keeping most of the data in the database and it will have a higher churn rate than any other table in the whole system. It stores a lot of referential ids from other tables than actual data e.g. pick \& drop address, person, company. It also consists of the status of the package which determines to be the major representative of package information.

\begin{table}[!ht]
\begin{center}
\begin{tabular}{ |l|l|l| }
 \hline
Id & Int - auto increment & Unique Order ID \\
 \hline

OrderID & Int - AutoIncrement  & \\
\hline
PickAddressID & Int & Pick up address id\\
\hline
DropAddresID  & Int  & Drop address Id\\
\hline
PickDate  & date & Registration or pick up date\\
\hline
ArrivalDate & date & Delivery date\\
\hline
PersonID & int & Package Sender id\\
\hline
ReceiverPersonID & int & Package Receiver id\\
\hline
Status & varchar & E.g. Registered, In-Transit or Delivered\\
\hline
CompanyId & int & Reference for associated company\\

 \hline
\end{tabular}
\end{center}
    \caption{Orders table}
\end{table}

\subsection{OrderSensors}
OrderSensors table consists of all the vital information of the sensor be it the threshold of the shock sensors or the threshold of the temperature sensors. It also consists of the values recorded for the package and is differentiated using the combination of OrderId and the SensorId entities being considered from the above tables.
\begin{table}[!ht]
\begin{center}
\begin{tabular}{ |l|l|l| }
 \hline
Id & Int - auto increment & Unique sensor ID \\
 \hline
OrderId & Int &  \\
 \hline
SensorOd & Int & \\
 \hline
MinThreshold & Int & Minimum Threshold for sensor\\
 \hline
MaxThreshold & Int & Maximum Threshold for sensor\\
 \hline
valuerecorded & Int & Value recorded by the sensor\\
 \hline
light & Int & Definition of light impact \\
 \hline
heavy & Int & Definition of heavy impact \\
 \hline
severe & Int & Definition of severe impact \\
 \hline
bclight & Int &  \\
 \hline
bcheavy & Int &  \\
 \hline
bcsevere & Int &  \\
 \hline
bctemprature & Int &  \\
 \hline
\end{tabular}
\end{center}
    \caption{OrderSensors table}
\end{table}

\subsection{Incident}

The Incident table consists of all incident raised by all users in the form of a unique incident Id and a brief description of the incident. It is linked with the user and the packages using the OrderId and the PersonId respectively.
\begin{table}[!ht]
\begin{center}
\begin{tabular}{ |l|l|l| }
 \hline
IncidentId & Int - auto increment & Unique Incident ID \\
 \hline
Description & varchar & Brief Incident Description \\
 \hline
OrderId & Int &  \\
 \hline
PersonId & Int &  \\
 \hline
\end{tabular}
\end{center}
    \caption{Incident table}
\end{table}

\subsection{Database Diagram}
\begin{figure}[!ht]
	\centering
	\includegraphics[width=1\textwidth]{images/IOSLDBDiagramlatex.png}\\
	\caption{Database Diagram}
	\label{fig:Database Diagram}
\end{figure}


text:
\input{preamble.tex}

\begin{document}
    \section{Omega and Z}
    \newcommand{\ThE}{thermal equilibrium}

        In this section, we want to answer why $Z$ is a more efficient technology than the good 'ol $\Omega$.
        \begin{align*}
            &P(\mu_i) = e^{-\beta E_i}
            \left( \frac{Z_{N-1}(\beta)}{Z_N(\beta)}\right)\\
            &P(\mu_1,\mu_2,\mu_3,\ldots) = \frac{e^{-\beta E_1} e^{-\beta E_2} e^{-\beta E_3} \cdots}{Z(\beta)}
                              = \frac{e^{-\beta E} }{Z(\beta)}\\
        \end{align*}

        %&=& &=& &=& &=& &=& &=& &=& &=& &=& =
        Let's zoom into the system to see what's really going in there.
        As usual, in \ThE, the probability of a microstate only depends on its energy.

            \[P(\mu_i) = \frac1{\Omega_1(E_{\mu_i})} \]
        \begin{align}
            P(\mu_1,\mu_2,\mu_3,\ldots) &= \frac1{\Omega_1(E_1)}
                                \frac1{\Omega_1(E_2)}
                                \frac1{\Omega_1(E_3)}
                                \ldots \\
            &= \frac1{\Omega_N(E)}
        \end{align}

        Notice that these equations already represent thermal equilibrium,
        since they are characterized only by energy.
        Thermal equilibrium is our one and only approximation\footnote{this includes the assumption that $\beta$ is constant in the range $E\pm\Delta E$},
        hence, one shouldn't expect to do more approximation in order to arrive at Z.\\
        There are three ways to exploit the relation between (1) and (2), but first I need to introduce several notations:

        %Preliminary
        \newcommand{\aE}{\epsilon}
        \newcommand{\soi}{\sum_i}
        \newcommand{\Stothei}[1] {{\hat\pdc}^{#1} S_1(\aE)}
        Equation (1) to (2) may look like a tiny step in \LaTeX,
        but it is actually a giant step.
        Rewrite $\Omega_1$ as $e^{ S_1}$, hence the relation becomes
        \begin{equation}
            \label{eq:mainassumption}
            \soi S_1(E_i) = S_N(E) = S_N\Big(\soi E_i\Big) \\
        \end{equation}

            \paragraph{1. principle of least assumption
            \footnote{a more mediocre and tedious derivation is given in the appendix}}
            For \eqref{eq:mainassumption} to be true,
            $S_N(E)$ must not depend on the spread of the $E_i$ distribution,
            where mathematically you can freely rearrange your energy distribution as you wish
            \[S_1(E_1) + S_1(E_2) = S_1(E_1+E_2) + S_1(0) \]
            From here we know that $S_1$ must be a linear function
            \[ S_1(x) = S_1(0) + \beta x\]
            where $\beta = \pdc S_1 = \mathrm{constant}$.

            Interpretations:
            \begin{itemize}
                \item Hey, the entropy is automatically maximized, too
                    (which means, it is redundant
                    to further assume that entropy is maximized).\\
                \item We can now write the probability as
                    \[ P(\mu_i) = e^{-S_1(0) -\beta E_i} \]
                \item any visual reasons on why the entropy increases linearly?
            \end{itemize}

            \paragraph{2. vary N}
            Back to one particle, we are now authorized to use this relation
            \begin{align*}
                &p(\mu_i) = \frac{\Omega_{N -1}(E-E_{\mu_i})}{\Omega_N(E)} \\
                &= \exp(\log\Omega_{N-1}(E-E_{\mu_i}) - \log \Omega_N(E))\\
                & = \frac{\Omega_{N-1}( E )}{\Omega_N(E)}
                    \exp( -\pd{}{E}\log \Omega_{N-1}E_i
                          - \frac12\pddc \log\Omega_{N-1}E_i^2
                          - \cdots
                          )\\
                & = \frac{\Omega_{N-1}( E )}{\Omega_N(E)}
                    \exp(-\beta E_i
                         -\frac12 \pd{\beta}{E} E_i^2
                         - \cdots  )\\
                & = \frac{\exp(-\beta E_i)}{Z_1(\beta,\mathcal{O}(E_i^2))}\\
            \end{align*}
            There are two completely different arguments
            to arrive at Boltzmann distribution:
            \begin{itemize}
                \item the multiplicity is maximized
                \item the state only depends on energy
            \end{itemize}

            Another way to look at thermal equilibrium:
            we randomly sample a small element of our system,
            and yet it will still look exactly the same
            as its parent system (redundancy of information, rescaling, whatever).

            Possible mathematical relations:
            \[Z_{1R}(\beta,E_i)  = \frac{\Omega_N(E)}{ \Omega_{N-1}(E)}
                             \frac1{\exp(+ \frac{\beta}{2C_v T}E_i^2
                                         - \cdots  )}\]
            Now we begin to see why we need log. All of our arguments
            \[\log Z_1 = \pd{}{N}\log \Omega_N(E)\]
            The difference between the two description is that
            the former gives us the real-life particle description,
            why the latter only tells us about the smoothed out representation of the system.

            In the Z description,
            we are instead viewing the system as a field (``N is not fixed'', but we don't care).\\
            %topic: http://ajp.aapt.org/resource/1/ajpias/v71/i11/p1136_s1

        \input{statmech2appendix.tex}

\end{document}


text:
% Copyright 2010-2019 by Renée Ahrens
% Copyright 2010-2019 by Olof Frahm
% Copyright 2010-2019 by Jens Kluttig
% Copyright 2010-2019 by Matthias Schulz
% Copyright 2010-2019 by Stephan Schuster
% Copyright 2019 by Jannis Pohlmann
% Copyright 2019 by Till Tantau
%
% This file may be distributed and/or modified
%
% 1. under the LaTeX Project Public License and/or
% 2. under the GNU Free Documentation License.
%
% See the file doc/generic/pgf/licenses/LICENSE for more details.

\section{The Binding Layer}
\label{section-gd-binding-layer}

\ifluatex
\else
    This section of the manual can only be typeset using Lua\TeX.
    \expandafter\endinput
\fi

\subsection{Overview}

This section explains how the \emph{binding} of the graph drawing system to a
particular display layer works. Let me stress that all of this is important
only for readers who
%
\begin{itemize}
    \item either wish to write new display system (see
        Section~\ref{section-gd-display-layer})
    \item or wish to know more about how the graph drawing system works on the
        pure \pgfname\ layer (this is were the binding occurs).
\end{itemize}

\emph{Bindings} are used to encapsulate the details of the communication
between the graph drawing system and a display system (see
Section~\ref{section-gd-display-layer} for an introduction to display systems).

Consider a display system that communicates with the graph drawing system. At
some point, the display system would like to run an algorithm to lay out a
graph. To achieve this, it will call different functions from the class
|InterfaceToDisplay| and the effect of this is that a representation of the
to-be-drawn graph is constructed internally and that the appropriate algorithms
are run. All of this is in some sense independent of the actual display system,
the class |InterfaceToDisplay| offers the same standard interface to all
display systems.

At some point, however, the graph drawing system may need to ``talk back'' to
the display system. For instance, once the graph has been laid out, to trigger
the actual rendering of the graph, the graph drawing system must ``tell'' the
display layer where the vertices lie. For some display systems this is easy: if
the display system itself is written in Lua, it could just access the syntactic
digraph directly. However, for systems like \tikzname\ or systems written in
another language, the graph drawing system needs a set of functions that it can
call that will tell the display system what is going on. This is were bindings
come in.

The class |Binding| is an interface that defines numerous methods that will be
called by the graph drawing system in different situations (see the
documentation below for details). For instance, there is a function
|renderVertex| that is called by the graph drawing system whenever a vertex
should be rendered by the display system. The class is really just an interface
in the sense of object-oriented programming. For each display system you need
to create a subclass of |Binding| like |BindingToPGF| or |BindingToASCII| that
implement the methods declared by |Binding|. The number of methods that need to
be implemented depends on the display system.

In the following, you will find the documentation of the |Binding| class in
Section~\ref{section-gd-binding-doc}. Following this, we first have a quick
look at how the |BindingToPGF| works and then go over a simple example of a
binding to a more or less imaginary display system. This example should help
readers interested in implementing their own bindings.

\subsection{The Binding Class and the Interface Core}
\label{section-gd-binding-doc}

\includeluadocumentationof{pgf.gd.bindings.Binding}
\includeluadocumentationof{pgf.gd.interface.InterfaceCore}

\subsection{The Binding To PGF}

\includeluadocumentationof{pgf.gd.bindings.BindingToPGF}

\subsection{An Example Binding Class}

\label{section-gd-binding-layer-example}

In the present section a complete binding is presented to an imaginary
``\textsc{ascii} art display system'' is presented. The idea is that this
display system will depict graphs using just normal letters and spaces so that,
when the text is typeset in a monospace font, a visualization of the graph
results. For instance:

\bigskip
\noindent
\begin{minipage}[t]{.5\textwidth}
\emph{Graph rendered by |BindingToPGF|:}
\medskip

\tikz [anchor=base]\graph [layered layout,level distance=2.35cm,sibling
distance=1.2cm,edges={rounded corners,>={Stealth[round,sep]}}] {
  Alice;
  Bob;
  Charly;
  Dave;
  Eve;
  Fritz;
  George;
  Alice -> Bob;
  Alice -> Charly;
  Charly -> Dave;
  Bob -> Dave;
  Dave -> Eve;
  Eve -> Fritz;
  Fritz -> Alice;
  George -> Eve;
  George -> Fritz;
  Alice -> George;
};
\end{minipage}%
\begin{minipage}[t]{.49\textwidth}
\emph{Graph rendered by |BindingToASCII|:}

\begin{verbatim}
                   Alice
                 .......
               .. .  .  .
            ...  .   .   .
         ...   ..    .    ..
       ..     .      .      .
  Charly    Bob      .       .
      ..     .       .       .
        .    .       .       .
         .   .       .       .
          .. .       .       .
            ..       .       .
           Dave   George     .
              ..     . ...   .
                .    .    .. .
                 .   .      ...
                  .. .       . ...
                    ..       .    ..
                    Eve      .      ..
                      ..     .     ..
                        .    .    .
                         .   .   .
                          .. . ..
                            ...
                           Fritz
\end{verbatim}
\end{minipage}
\bigskip

The binding will reside in a file |BindingToASCII.lua|, whose contents is
detailed below, and which is used by calling the |bind| function of
|InterfaceToDisplay|, see its documentation for details.

The binding's code starts with some initializations:
%
\begin{codeexample}[code only]
-- File BindingToASCII.lua

-- Imports
local lib = require "pgf.gd.lib"

-- Subclass the Binding class:
local BindingToASCII = lib.class { base_class = require "pgf.gd.bindings.Binding" }
\end{codeexample}

The interesting code is the code for ``rendering'' a graph. The graph drawing
system will invoke the binding's methods |renderStart| and |renderStop| to
signal that the graph drawing algorithms have finished and that the vertices
and edges can now be drawn.

In our \textsc{ascii} renderer, we use a two-dimensional field holding
characters that severs as the ``drawing canvas''. At the beginning of the
rendering, we initialize it with blanks:
%
\begin{codeexample}[code only]
local canvas

function BindingToASCII:renderStart()
  canvas = {}
  -- Clear the canvas
  for x=-30,30 do
    canvas [x] = {}
    for y=-30,30 do
      canvas[x][y] = ' '
    end
  end
end
\end{codeexample}

In order to ``render'' a vertex, the graph drawing system will call the
|renderVertex| method. The binding of \tikzname\ does a lot of complicated
things in this method to retrieve the underlying node's box from internal table
and to somehow reinstall the box in \TeX's output stream; for our
\textsc{ascii} binding things are much simpler: We simply put the vertex's name
at the canvas position corresponding to the vertex's |pos| coordinate. Note
that this simple version of an \textsc{ascii} renderer does not try to scale
things; thus, array out of bounds might occur here.
%
\begin{codeexample}[code only]
function BindingToASCII:renderVertex(v)
  canvas [math.floor(v.pos.x)][math.floor(v.pos.y)] = v.name
end
\end{codeexample}

The rendering of edges is a more complicated process. Given two vertices, we
put dots at the canvas positions between them; provided there are no vertices
(so edges are behind the nodes). Here is the essential part of the code (for
the complete code, have a look at |pgf/gd/examples/BindingToASCII.lua|):
%
\begin{codeexample}[code only]
function BindingToASCII:renderEdge(e)
  local function connect (p,q)
    -- Connect the points p and q
    local x1, y1, x2, y2 = math.floor(p.x+0.5), math.floor(p.y+0.5), math.floor(q.x+0.5), math.floor(q.y+0.5)
    ...
    local delta_x = x2-x1
    local delta_y = y2-y1
    ...
      local slope = delta_y/delta_x
      for i=x1,x2 do
        local x,y = i, math.floor(y1 + (i-x1)*slope + 0.5)

        if canvas[x][y] == " " then
          canvas[x][y] = '.'
        end
      end
    ...
  end

  -- Iterate over all points on the path from tail to head:
  local p = e.tail.pos
  for i=1,#e.path do
    connect(p, e.tail.pos + e.path[i])
    p = e.tail.pos + e.path[i]
  end
  connect(p, e.head.pos)
end
\end{codeexample}

The methods |renderVertex| and |renderEdge| will be called once for each vertex
and edge of the to-be-rendered graph. At the end, the |renderStop| method is
called. In our case, this method will output the canvas using |print|. A slight
complication arises when node names are longer than just one character. In this
case, the following code ``centers'' them on their coordinate and makes sure
that they do not get overwritten by the dots forming edges:
%
\begin{codeexample}[code only]
function BindingToASCII:renderStop()
  for y=10,-30,-1 do
    local t = {}
    for x=-30,30 do
      local s = canvas[x][y]
      for i=1,#s do
        pos = x+30+i-math.floor(#s/2)
        if not t[pos] or t[pos] == " " or t[pos] == "." then
          t[pos] = string.sub(s,i,i)
        end
      end
    end
    print(table.concat(t))
  end
end
\end{codeexample}

At the end, we need to return the created object:
%
\begin{codeexample}[code only]
return BindingToASCII
\end{codeexample}


text:
%-------------------------
% Resume in Latex
% Author : Sourabh Bajaj
% License : MIT
%------------------------

\documentclass[letterpaper,11pt]{article}
\usepackage[lithuanian]{babel}
\usepackage[utf8x]{inputenc}

\usepackage{latexsym}
\usepackage[empty]{fullpage}
\usepackage{titlesec}
\usepackage{marvosym}
\usepackage[usenames,dvipsnames]{color}
\usepackage{verbatim}
\usepackage{enumitem}
\usepackage[hidelinks]{hyperref}
\usepackage{fancyhdr}

\pagestyle{fancy}
\fancyhf{} % clear all header and footer fields
\fancyfoot{}
\renewcommand{\headrulewidth}{0pt}
\renewcommand{\footrulewidth}{0pt}

% Adjust margins
\addtolength{\oddsidemargin}{-0.5in}
\addtolength{\evensidemargin}{-0.5in}
\addtolength{\textwidth}{1in}
\addtolength{\topmargin}{-.5in}
\addtolength{\textheight}{1.0in}

\urlstyle{same}

\raggedbottom
\raggedright
\setlength{\tabcolsep}{0in}

% Sections formatting
\titleformat{\section}{
  \vspace{-4pt}\scshape\raggedright\large
}{}{0em}{}[\color{black}\titlerule \vspace{-5pt}]

%-------------------------
% Custom commands
\newcommand{\resumeItem}[2]{
  \item\small{
    \textbf{#1}{: #2 \vspace{-2pt}}
  }
}

\newcommand{\resumeSubheading}[4]{
  \vspace{-1pt}\item
    \begin{tabular*}{0.97\textwidth}[t]{l@{\extracolsep{\fill}}r}
      \textbf{#1} & #2 \\
      \textit{\small#3} & \textit{\small #4} \\
    \end{tabular*}\vspace{-5pt}
}

\newcommand{\resumeSubItem}[2]{\resumeItem{#1}{#2}\vspace{-4pt}}

\renewcommand{\labelitemii}{$\circ$}

\newcommand{\resumeSubHeadingListStart}{\begin{itemize}[leftmargin=*]}
\newcommand{\resumeSubHeadingListEnd}{\end{itemize}}
\newcommand{\resumeItemListStart}{\begin{itemize}}
\newcommand{\resumeItemListEnd}{\end{itemize}\vspace{-5pt}}

%-------------------------------------------
%%%%%%  CV STARTS HERE  %%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{document}

%----------HEADING-----------------
\begin{tabular*}{\textwidth}{l@{\extracolsep{\fill}}r}
  \textbf{\href{https://dovydasvenckus.com/}{\Large Dovydas Venckus}} & Email : \href{mailto:dovydas.venckus@live.com}{dovydas.venckus@live.com}\\
  \href{https://dovydasvenckus.com/}{https://dovydasvenckus.com} & Mobile : +370-67802390
\end{tabular*}

%-----------EDUCATION-----------------
\section{Education}
  \resumeSubHeadingListStart
    \resumeSubheading
      {Vilnius University}{Vilnius, Lithuania}
      {Bachelor of Software engineering}{2011 -- 2017}
    \resumeSubheading
      {Kretinga Jurgis Pabrėža gymnasium}{Kretinga, Lithuania}
      {School}{1999 -- 2011}
  \resumeSubHeadingListEnd

%-----------EXPERIENCE-----------------
\section{Experience}
  \resumeSubHeadingListStart

    \resumeSubheading
      {4Finance}{Vilnius, Lithuania}
      {Java Software developer}{July 2017 - Now}
      \resumeItemListStart
      \resumeItem{Work}

      Working with same technologies as in previous position.

      \resumeItem{Hiring}

      Started to actively participate in hiring processes. It includes
      reviewing candidate homework and participating in technical interviews.

      \resumeItem{Mentoring}

      Mentoring and helping other new employees. Took initiative to train the first
      intern in our department.
      \resumeItemListEnd

    \resumeSubheading
      {4Finance}{Vilnius, Lithuania}
      {Junior Java developer}{April 2016 - July 2017}
      \resumeItemListStart
      \resumeItem{Work}

      Worked on a wide range of projects, from monoliths to microservices.
      My work ranged from support tasks to new feature implementation.

      I have mainly worked with Java 8 and current Spring technologies.
      I have used Groovy and Spock mainly for writing unit and integration tests.

      Also, I have gained some experience in writing acceptance tests using Cucumber.

      Conducting code reviews
      \resumeItemListEnd

    \resumeSubheading
      {Dekbera}{Vilnius, Lithuania}
      {Junior Java developer}{October 2014 - April 2016}
      \resumeItemListStart
        \resumeItem{Real-time map with Google API}

          Created a new web application using Grails framework.
          Using Google Maps API I have developed a real-time map of moving vehicles.
          Also, I have used Google Maps API for historical data visualization.

          \resumeItem{Network devices health check system}

          Created system that collects data from registered devices. Implemented
          notification sending when device parameters were not in defined ranges.

          \resumeItem{Small web service}

          I also developed a small SOAP web service which used Java, Spring, Hibernate, and Apache CXF technologies.
          To ensure expected behavior I have covered in unit tests.
      \resumeItemListEnd

  \resumeSubHeadingListEnd

%-----------PROJECTS-----------------
% \section{Projects}
%   \resumeSubHeadingListStart
%     \resumeSubItem{QuantSoftware Toolkit}
%       {Open source python library for financial data analysis and machine learning for finance.}
%     \resumeSubItem{Github Visualization}
%       {Data Visualization of Git Log data using D3 to analyze project trends over time.}
%     \resumeSubItem{Recommendation System}
%       {Music and Movie recommender systems using collaborative filtering on public datasets.}
%     \resumeSubItem{Mac Setup}
%       {Book that gives step by step instructions on setting up developer environment on Mac OS.}
%   \resumeSubHeadingListEnd

\section{Programming Skills}
 \resumeSubHeadingListStart
   \item{
     \textbf{Languages}{: Java, Groovy, Python, Ruby}
     \hfill
     \textbf{Technologies}{: Spring, JPA, Hibernate, ActiveMQ, Jersey}
   }
   \item{
     \textbf{Testing technologies}{: JUnit, Spock, Cucumber}
     \hfill
     \textbf{Front end technologies}{: Aurelia, Knockout.js}
   }
   \item{
     \textbf{Tools \&OS}{: Linux, Docker, Git, Mercurial, Maven, Gradle}
     \hfill
     \textbf{Databases}{: PostgreSQL, MySQL}
   }
 \resumeSubHeadingListEnd

%-------------------------------------------
\end{document}

max_stars_repo_name: dovydasvenckus/resume

max_issues_repo_name: dovydasvenckus/resume

max_forks_repo_name: dovydasvenckus/resume


text:
%!TEX root = ../notes.tex
\section{April 25, 2022}
\subsection{Babai's Algorithm \emph{continued}}

\recall We revisit some topics from before. We reverse our original course and use \textsf{sage} instead of \textsf{numpy}. (For symbolic math).

\lstinputlisting[]{code/hadamard_ratio.sage}

\begin{proposition}
    If $\bvec{v}_i$ is orthogonal, then Babai's Algorithm solves CVP.
\end{proposition}
\begin{proof}
    We have some
    \[\bvec{w} = \sum a_i\bvec{v}_i\]
    and we want to minimize
    \begin{align*}
        \left\lVert \bvec{w} - \sum \alpha_i\bvec{v}_i\right\rVert^2
         & = \left\lVert \sum(a_i - \alpha_i)\bvec{v}_i\right\rVert^2 \\
         & = \sum (a_i - \alpha_i)^2||\bvec{v}_i||^2
    \end{align*}
    and this is minimized when $\alpha_i$ is the closest integer to $a_i$ for all $i$.
\end{proof}

We start using this theory of lattices to develop cryptosystems\dots

\subsection{GGH Cryptosystem: Digital Signatures}
\ul{Alice}: Chooses $\{\bvec{v}_i\}$ a good basis for some lattice. This is Alice's \emph{private key}.

Alice computes a \emph{bad basis} $\bvec{w}_i = U\cdot \bvec{v}_i$ (for $n\times n$ matrix $U$ with $\det U = 1$). Note that $\bvec{w}_i$ is still a basis for the same lattice.

\emph{How does Alice sign a document $\bvec{d}\in\ZZ^n$? }
\begin{enumerate}
    \item Apply Babai's algorithm to find a close lattice vector.
    \item Express answer $\sum a_i\bvec{w}_i$ in the bad basis.
\end{enumerate}

\emph{How does Bob verify that this is the correct document? }

Bob checks how close the document $\bvec{b}$ to $\sum a_i \bvec{w}_i$.

\emph{How do we generate $U$?}
\begin{enumerate}
    \item Start with identity matrix $I$.
    \item Apply some random row operations.
\end{enumerate}

(Code is in \textsf{lattices.ipynb})


text:
% ---------------------------------------------------
% CHAPTER SUMMARY MESSAGE: < WRITE THIS BEFORE ANY EDITING>
% ---------------------------------------------------

%Contributors: Igor Lakomov (ALICE), Konstantin Kanishchev (AMS-02), Konstantin Skazytkin
%(ALICE), Jonas Eschle (LHCb), Alexander Kurepin (ALICE), Andrey Ustyuzhanin (Yandex,
%LHCb), Michela Paganini (ATLAS), Gabriel Perdue (MINERvA), Ryan Reece (ATLAS),
%Sean-Jiun Wang (CMS), Sergei Gleyzer (CMS), Meghan Kane (Industry - SoundCloud), Steven Schramm (ATLAS), Eduardo Rodrigues (LHCb), Martin Erdmann, Patrick Koppenburg (Nikhef, LHCb)

\subsection{Introduction}

Discovery science provides a challenge that attracts brilliant minds eager to push the boundaries of scientific understanding of nature. Particle physics has a rich problem domain that offers avenues for intellectual reward. The goal is to achieve a vibrant collaboration between the data science and high-energy physics communities by finding a common language and working together to further science.
%Before building collaborations, it is important to have a coherent strategy and vision of how to engage other communities.
Both communities can benefit from such collaboration. The HEP community can explore new research directions and applications of machine learning, novel algorithms, and direct collaboration on HEP challenges. The ML community can benefit from a diverse set particle physics problems with unique challenges in scale and complexity, and a large community of researchers that can expand the machine learning horizon by contributing to solving problems relevant to both communities. For example, the treatment of systematic uncertainties is an important topic for the HEP and ML communities. By working together on common challenges, the two fields can further progress in solving such problems.\\

There are a number of existing examples of collaboration between HEP and ML that have produced fruitful results through mostly local connections (e.g.~\cite{Likhomanenko:2016tgu,Paganini:2017hrr,darkmachines} ). The HEP community should continue such collaborations and look for additional collaborations with the ML community.\\

The HEP community needs to define its challenges in a language that the ML community can understand. This may involve only retaining necessary information with clear and concise explanations as to its relevance. Machine learning likewise has a significant amount of domain knowledge. Ideas and solutions provided by both communities should be presented in an understandable way for scientists without in-depth knowledge.

\subsection{Academic Outreach and Engagement}

Direct collaboration between HEP researchers and computer scientists working in the area of machine learning is an important possible driver of innovation in the area of machine learning applications described in Section~\ref{sec:applications}.
It is important for high-energy physics to engage and collaborate with the academic community focused on new machine learning algorithms and applications as they will naturally be interested in applying new ideas to interesting and complex data provided by HEP.\\

Conferences and workshops are a core aspect of the academic ML community, and organizing or contributing to key conferences is a means of gaining interest.
Organizing sessions or mini-workshops within major ML conferences, such as NIPS, would increase the familiarity of HEP within the ML community and jump-start future collaborations.
This has been explored in single cases~\cite{NIPS:2015:ALEPH} but is not an established, regular workshop series.
At the same time inviting ML experts to HEP workshops, as done at~\cite{FlavourDataMining} and the DS@HEP series~\cite{DSatHEP2015, DSatHEP2016, DSatHEP2017}, can foster greater long-term collaboration.
There should be coordinated efforts to:
\begin{itemize}
 \item Organize workshops and conferences open to external collaborators to discuss applications, algorithms and tools
 \item Organize thematic workshops around topics relevant to HEP
       %\item Engage machine learning experts by creating prestigious fellowships and data-science related initiatives
\end{itemize}

%\subsection{Science outreach}
HEP should reach out to other scientific communities with similar challenges, for example astrophysics/cosmology, medium energy nuclear physics and computational biology. This can lead to more active partnerships to better collaborate on ideas, techniques, and algorithms.

%[ A comment : I see that wrt the version I printed (June) the scope has been reduced to reflect what is actually described in Sec.6: collaboration between HEP and ML communities. I find that a bit sad as one could (should?) think of other fields of science that use ML a lot. Astrophysics is mentioned above, but social sciences and genomics face similar challenges. A quick search for ML in bioRxiv is enlightening. Could this section be expanded a bit?  ]

\subsection{Machine Learning Challenges}

To engage the wider ML community, challenges such as the Higgs Boson Challenge (2014) or the Flavor Physics Challenge~\cite{NIPS:2015:ALEPH,FlavourDataMining} have been organized on Kaggle.
These types of challenges draw considerable attention from the machine learning community and additional similar challenges should be organized in the future.\\

Organization of a challenge requires a well documented dataset, a starting-kit and an evaluation metric to rank the solutions.
This forces the organizers to simplify the problem as much as possible, while retaining its intrinsic complexity.
The drawback of challenges is that once they are launched, participants priority is winning the challenge and not eventual collaboration with HEP.
It is important to foresee upfront a way to integrate incoming solutions, for example via forums and post-challenge workshops (like~\cite{FlavourDataMining}) where a diversity of competitive algorithms can be presented.
The challenge dataset and evaluation metric should be released publicly so that further developments can continue.

\subsection{Collaborative Benchmark Datasets}\label{subsec:benchmark}
There is a strong incentive for HEP to develop public benchmark datasets, beyond just challenges. Access to a dataset makes the discussion much more concrete and productive. Within the HEP community, common datasets enable comparisons of algorithms with much better accuracy, which is very useful for research and development. The same benchmark datasets can also be used for teaching, tutorials and training.\\

These benchmark datasets could be built based on public simulation engines or released by experiments within the bounds of their data access policy. Even a small subset of an experiment's simulated data can be the base of a very valuable benchmark dataset. For example, the CMS experiment has released a significant amount of its simulated and collected data via the CERN Open Data Portal~\cite{opendata}.\\

To be maximally useful, the subsequent guidelines should be followed when designing a benchmark dataset:
\begin{itemize}
 \item Simplify the dataset as much as possible while conserving all methodical difficulties relevant to solving the problem
 \item Document the dataset to make it understandable by a non-HEP expert
 \item Create methodologies and metrics for the evaluation of proposed solutions, and document them
 \item Prepare an integration plan for incoming ideas and solutions
 \item Feedback results of successful applications
\end{itemize}

%\subsection{Collaborative Benchmark Datasets}

%As discussed in Section~\ref{subsec:benchmark}, collaborative benchmark datasets can be useful for developing ML challenges and for collaboration with the ML community.

The HEP community should organize and curate a variety of such benchmark datasets covering its current physics drivers and make them publicly available. To improve the reproducibility of results and algorithm comparisons, some of the data used for evaluation of the solutions should be kept private.
%an effort known as TrackingML is underway to create datasets and establish a challenge to elicit solutions from the broader ML community, Move to bridges.
Additionally, after investing heavily into producing highly-detailed and realistic simulations, the HEP community can provide the machine learning community with labeled datasets with high statistical power to test algorithms and develop novel ideas.

%\subsection{Communication and Outreach}
%A multi-prong strategy for engaging the ML community is presented, targeting different areas: academia, industry and the ``general public''.

%\subsection{Inter-experimental Collaboration}
%to be added

\subsection{Industry Engagement}
Industry has been focused on the development and adoption of machine learning techniques. In addition to algorithm and software development, one of the promising areas is the adoption of dedicated specialized hardware and high performance co-processors. GPUs, FPGAs, and high core count co-processors all have the potential to dramatically increase performance of machine learning applications relevant to the HEP community.
One of the challenges is gaining the human expertise for development and implementation. Industry interactions bring specific technology opportunities and access to specialized expertise that can be difficult to hire and support internally.\\

There are specific areas of development where industry has expressed interest in collaborating with HEP.  Automated resource provisioning, data placement, and scheduling are similar to industrial applications to improve efficiency. Applications such as data quality monitoring, detector health monitoring and preventative maintenance can be automated using techniques developed for other industrial quality control applications. There are two more forward looking areas that coincide with HEP physics drivers, namely computer vision techniques for object identification and real-time event classification. These present a challenge to industry due to its complexity and benefit outside of HEP.\\

%		\item Bridge to industry (partnerships in applying externally developed techniques and tools to HEP problems anomaly detection against fraud transactions, spam filtering etc)

%\subsubsection{CERN OpenLab and research-industry collaborative initiatives}
CERN OpenLab is a public-private partnership that accelerates the development of cutting-edge solutions for the LHC community and wider scientific research. CERN OpenLab has established the infrastructure to maintain non-disclosure agreements, to arrange ownership of intellectual property, and to provide an interface between CERN and industry. As part of its upcoming phases, OpenLab plans to explore machine learning applications for the benefit of LHC experiments computing and the HL-LHC. Such initiatives and industry partnerships should be supported in the future.

%Through CERN openlab, CERN collaborates with leading ICT companies and research institutes. Within the CERN openlab framework, CERN provides access to its complex ICT infrastructure and its engineering experience — in some cases even extended to collaborating institutes worldwide. Testing in CERN's demanding environment provides the collaborating companies with valuable feedback on their products, while enabling CERN to assess the merits of new technologies in their early stages of development for possible future use.

%CERN openlab is continuing its work to support CERN’s research community, with a particular focus on the upgrades to the LHC and the detectors that will be carried out during LS2 and LS3. With the data rates from the experiments set to increase significantly, efforts have been focused on supporting the work to overhaul and modernise their data-acquisition systems, while also ensuring that the maximum benefits are gained from the hardware available to CERN’s teams by making sure the software running on it has been fully optimised. Efforts have now begun to identify the ICT challenges that will be tackled in CERN openlab’s sixth phase (2018 to 2020).

%One of the most significant technical challenges facing CERN is how to provision computing for the LHC experiments and the accelerator for the HL-LHC.
%In order to tackle said challenge, CERN openlab Phase VI will choose projects that are intended to help close the gap and deliver the evolutionary and revolutionary changes needed for the success of the program. The exploration of new applications of Machine Learning techniques aligns with the goals of industry and the next phase of CERN openlab.

%The work areas are divided into three sections that will be expanded below: research and development (R\&D) for data centre technologies and infrastructure, R\&D for software and computing performance, and R\&D for machine learning and data analytics. In particular, for its Phase VI, CERN openlab is in the process of investigating the opportunity of establishing a number of key projects in machine learning for data taking, triggering, simulation, reconstruction, detector and data quality monitoring with leading companies in deep learning technologies.

\subsection{Machine Learning Community-at-large Outreach}
Another form of engagement is using the communications mediums to broadcast our challenges and attract interested collaborators. There are a variety of channels which can be leveraged to increase the visibility of our problems and research opportunities in the ML community. These can be popular forums such as reddit, personal or official blogs, social media, or direct contact with influential personalities.\\

%\subsubsection{Podcasts, Blog Posts and Meetups}
Podcasts have shown to be a great vehicle for reaching a large audience. Listeners are keen to consume material that is outside of their immediate problem domain in a way that is easy to digest. There is an abundance of machine learning podcasts with a large base of listeners that can be targeted for outreach:
\begin{itemize}
 \item \href{http://lineardigressions.com/}{\textcolor{blue}{Linear Digressions}} (co-hosted by former ATLAS Ph.D. Katie Malone)
 \item \href{http://partiallyderivative.com/}{\textcolor{blue}{Partially Derivative}}
 \item \href{http://www.thetalkingmachines.com/}{\textcolor{blue}{Talking Machines}}
 \item \href{https://dataskeptic.com/}{\textcolor{blue}{Data Skeptic}}
 \item \href{http://becomingadatascientist.com/}{\textcolor{blue}{Becoming a Data Scientist Podcast}}
 \item \href{https://itunes.apple.com/us/podcast/not-so-standard-deviations/id1040614570?mt=2}{\textcolor{blue}{Not So Standard Deviations}}
 \item \href{https://twimlai.com/}{\textcolor{blue}{This Week in ML \& AI}}
\end{itemize}

%Some examples are (Partially Derivative Episode: \href{http://partiallyderivative.com/podcast/2017/02/28/michael-kagan}{``Particle Physics and Machine Learning at CERN with Michael Kagan''}) as well as applications of programming and technology in physics (Talk Python To Me Episode \#29: ``\href{https://talkpython.fm/episodes/show/29/python-at-the-large-hadron-collider-and-cern}{Python at the Large Hadron Collider and CERN}'' with Kyle Cranmer).

%Bringing together tangentially related fields is commonplace in ML podcasts. For example, podcasts such as This Week in Machine Learning (TWiML) features machine learning experts across a wide variety of problem domains, spanning topics from a  \href{https://twimlai.com/twiml-talk-12-brendan-frey-reprogramming-human-genome-w-ai/}{\textcolor{blue}{genomics}} to \href{https://twimlai.com/twiml-talk-027-intelligent-autonomous-robots-ilia-baranov/}{\textcolor{blue}{robotics}} to \href{https://twimlai.com/twiml-talk-5-joshua-bloom-machine-learning-stars-productizing-ai/}{\textcolor{blue}{astrophysics}}.Podcasts typically consist of a casual conversation from 30 minutes to an hour. Therefore, there is a high yield in the form of listeners versus time investment required to release a podcast.
%\subsubsection{Blog Posts}

Another form of engagement is through outreach-style blog posts to explain HEP challenges in a way that is easy to understand by the public.\\

Another outreach opportunity is to make HEP related presentations at machine learning Meetups across the world to generate awareness, engage community, foster cross pollination of ideas between HEP and industry. Some popular ML meetups are:
\begin{itemize}
 \item NYC: \url{https://www.meetup.com/NYC-Machine-Learning/}
 \item Berlin: \url{https://www.meetup.com/Advanced-Machine-Learning-Study-Group/}
 \item SF: \url{https://www.meetup.com/SF-Bayarea-Machine-Learning/}
\end{itemize}

In conclusion, existing outreach efforts should be expanded to attract greater collaboration between the HEP and ML communities. By understanding and speaking the same language, the two communities can better collaborate and find solutions to present and future challenges.

%Section outline:
%\begin{itemize}
%	\item Describe the need for a bridge and its benefits
%	\item Explain community differences
%	\item ML rapid experimentation
%	\item ML and HEP Domain knowledge differs (need to be able to communicate)
%	\item Roadmap to creating a bridge
%	\item Define the problem
%	\item Discuss a common approach within HEP for reaching out to ML
%	\item Reach out to ML
%	\item Become more involved members of the ML community
%	\item Support new collaborations between HEP-ML
%	\item Make benefits of collaborations accessible to the community
%\end{itemize}

max_stars_repo_name: iml-wg/cwp

max_issues_repo_name: iml-wg/cwp

max_forks_repo_name: iml-wg/cwp


text:
\begin{table}[H]
    \centering
    \begin{tabular}{||c|c|c||}
        \hline
        Input (Motor) Power & \(P_{input}\) & \(90 Watts\) \\
        \hline
        Input (Motor) Torque @ Nominal & \(\tau_{input}\) & \(0.560 Nm\) \\
        \hline
        Input (Motor) Speed @ Nominal & \(\omega_{input}\) & \(2510 rpm\) \\
        \hline
        Input (Motor) Stall Torque & \(\tau_{in\_stall}\) & \(7.480 Nm\) \\
        \hline
        Gearbox Ratio & \(\frac{n_1}{n_2}\) & \(100:1\) \\
        \hline
    \end{tabular}
    \caption{Motor/Gearbox Specifications}
    \label{table:ApxMotorGearboxSpecs}
\end{table}

\subsubsection{Power Calculation}
\begin{equation}
    P_{output} = \epsilon P_{input} = 0.9 * 90W = 81W
     \label{eq:PowerCalc}
\end{equation}

\subsubsection{Torque Calculation}
\begin{equation}
    \tau_{output} = \epsilon  \tau_{input} \frac{n_1}{n_2} = 0.9 * 0.560 Nm * \frac{100}{1} = 50.4 Nm
    \label{eq:TorqueCalc}
\end{equation}

\subsubsection{Speed Calculation}
\begin{equation}
    \omega_{output} = \omega_{input}  \frac{n_2}{n_1} = 2510 rpm * \frac{100}{1} = 25.10 rpm = 150.6^\circ/sec
    \label{eq:SpeedCalc}
\end{equation}

\begin{table}[H]
    \centering
    \begin{tabular}{||c|c|c||}
        \hline
        Output Power & \(P_{output}\) & \(81 Watts\) \\
        \hline
        Output Torque @ Nominal & \(\tau_{input}\) & \(50.4 Nm\) \\
        \hline
        Output Speed @ Nominal & \(\omega_{input}\) & \(150.6^\circ/sec\) \\
        \hline
        Output Stall Torque & \(\tau_{out\_stall}\) & \(673.2 Nm\) \\
        \hline
    \end{tabular}
    \caption{Joint Output Specifications}
    \label{table:ApxJointSpecs}
\end{table}


text:
\chapter{Tiamat}

\begin{enumerate}
	\item Go to the clan hall, talk to Montblanc to get a lot of items.
	\item Buy Traveler, make sure that you have 500 gil left for the Chocobo. If you don't have enough gil, then check the next shop to see what is safe to sell.
	\item Ride a Chocobo to Jahara
	\item Get the Jaya Stick, continue
	\item Get on the chocobo, \pickup{Red Cap, Golden Amulet}{2 chests in the Ozmone Plains}
	\item Party: \vaan, \basch, \penelo
\end{enumerate}
\begin{liscense}
	\begin{itemize}
		\startLic{basch}{%
		\item Nothing
		      }
		      \nextLic{ashe}{%
		\item Rods 1
		      }
		      \nextLic{penelo}{%
		\item Rods 1
		      \downl{Staves 2}
		      }
		      \nextLic{ashe}{%
		\item Staves 2
		      }
		      \nextLic{vaan}{%
		\item $\nearrow\nearrow$: Shields 1
		      \rightl{Light Armor 3}
		      \rightl{Heavy Armor 3}
		      \rightl{Heavy Armor 4}
		\item $\uparrow\leftarrow$: Light Armor 5
		      }
		      \nextLic{basch}{%
			      \downl{Heavy Armor 3}
			      \upl{Light Armor 5}
		      }
		      \nextLic{penelo}{%
			      \uprightl Headsman on other board
		      }
		      \nextLic{balthier}{%
		\item $\rightarrow x4$: Poach
		      \downl{Traveler}
		      }
		      \nextLic{penelo}{%
		\item $\uparrow x7 \leftarrow$: Black Magics 3
		      }
		      \nextLic{ashe}{%
		\item Black Magics 3
		      }
	\end{itemize}
\end{liscense}
\begin{enumerate}
	\item Use \penelo\ to try and Berserk \basch, then get back on the chocobo.
	\item Dismount the Chocobo before the cutscene at the barrier. Swap \basch\ with \balthier\ if Berserk landed.
	\item Complete Eruyt, then Teleport to Jahara
\end{enumerate}
\begin{shop}{2\,500}
	\sell{Longsword, Bowgun, Killer Bow, Assassin's Dagger, Escutcheon, Bangle, Tourmaline Ring, Electrum, Arcana x2}
	\buy{Shielded Armor (or Brigandine if your money is super low), Flame Staves up to 2, Gold Needle up to 1, Phoenix Downs up to 4, Red Cap \textit{if you have 23k Gil}, Elixers Healing Items and Mythril Blade if needed}
	Need to have 30 gil left over.

	Always keep: Teleport Stone, Warp Mote, Flame and Cherry Staves, Cypress Poles, Mystic Armors
\end{shop}
\begin{enumerate}
	\item Get on Chocobo. When you get off, check for chest, and try to Berserk \basch\ with \penelo\ and then \vaan, then get back on the Chocobo. If you land it, take him out of the party for \balthier.
	\item Get on chocobo again, can repeat the berserk before the loading zone.
	\item \textit{If you have Brigandine:}
	      \begin{enumerate}
		      \vaanf Protect \vaan\ while running, make sure it's up for Tiamat. Larsa has healing gambits, so can stop \flee\ if anyone is below 50\%
	      \end{enumerate}
	\item Cast Traveler, open the Menu to check Step Count and make note of it. Turn Battle Speed to Min.
	\item Battle Speed to Max. Berserk \balthier
\end{enumerate}
\begin{battle}{Tiamat}
	\begin{itemize}
		\item Change Party: \vaan, \balthier, \basch, Larsa (if he doesn't open with Disablega)
		      \vaanf Phoenix Down Tiamat to draw aggro
		      \vaanf Dark x2, Equip Magicite
		      \vaanf Phoenix Down Tiamat
		      \balthierf Check your step counter to make sure that the last 3 digits don't go above whatever you had before, should be within 1-10 of the previous value. Use Traveler when he flashes Red
	\end{itemize}
\end{battle}

max_stars_repo_path: Final Fantasy XII/Sections/tiamat.tex

max_stars_repo_name: HannibalSnekter/Final-Fantasy-Speedruns

max_issues_repo_path: Final Fantasy XII/Sections/tiamat.tex

max_issues_repo_name: HannibalSnekter/Final-Fantasy-Speedruns

max_forks_repo_path: Final Fantasy XII/Sections/tiamat.tex

max_forks_repo_name: HannibalSnekter/Final-Fantasy-Speedruns