\documentclass{slides}                % Package for slides
\usepackage{amsmath,amssymb,amsfonts} % Typical maths resource packages
\usepackage{graphics}                 % Packages to allow inclusion of graphics
\usepackage{color}                    % For creating coloured text and background
\usepackage{hyperref}                 % For creating hyperlinks in cross references




\def\R{\mathbb{ R}}

\def\R{\mathbb{R}}

\definecolor{red}{rgb}{1,0,0}           % Standard colours red, green, blue
  \definecolor{green}{rgb}{0,1,0}
  \definecolor{blue}{rgb}{0,0,1}
  
\definecolor{Light}{gray}{.80}          % How you can define your own greys
\definecolor{Dark}{gray}{.20}
\definecolor{pink}{rgb}{.95,0.82,0.92}  % How you can define your own colours

\begin{document}

\pagecolor{Light}

{\fcolorbox{white}{Dark}{\color{white}
{\large\bf JE Moody \& Co, LLC }}\\
{\large\bf Summer Projects - 2006 }}\\

\hspace*{1cm}
{\small\bf Derek Cook}



\newpage
{\large\bf Specific Projects}
\begin{itemize}
\item Widget Alerts
\item Data Collection
\item Transaction Costs
\end{itemize}

{\small
{\large\bf Miscellaneous Tasks}
\begin{itemize}
\item Performance Correlations
\item Intra-daily Patterns
\item Widget Intra-daily Range 
\item Options Data Gathering
\item Build $N$ Minute Bars
\end{itemize}
 }

\newpage
{\large\bf Widget Alerts} - Can be broken down into:
{\small 
\begin{itemize} \itemsep 0pt
\item Building contract parameter files.

{\tiny
\begin{itemize} \itemsep 0pt
\item Contracts can be nuts/bolts e.g. 'CLQ06', or widgets, 'NGV06NGX06'.
\item Uses most recent 120K ticks of bid/ask/last data for nuts/bolts and simply last data for widgets.
\item Computes parameters used in filtering - thresholds, pit hours, median spreads
\end{itemize}}

\item Filtering \& cleaning tick data in real time.
{\scriptsize
\begin{itemize} \itemsep 0pt
\item Sequence of tests - thresholds, slippage, fluctuation, sign checks, staleness, tightness, looseness
\end{itemize}}

\item Building widget prices.  
{\scriptsize
\begin{itemize}\itemsep 0pt
\item Final 'sparseness' checks for combining data;  would like them to be similar in time and space.
\item Special moving median calculation for widget price which gives more weight to actual widget trades.
\end{itemize}}

\item Triggering alerts.
{\tiny
\begin{itemize}\itemsep 0pt
\item Alerts can be triggered by either actual widget trade or moving median calculation.
\item Based on sell stops/buy stops from configuration file.
\item Sounds an audio alert and emails myself \& Aron's phone.
\end{itemize}}

\end{itemize}}

\newpage
\begin{picture}(300,220)(0,0)           %% Slides use just picture environment
\put(-40,-60){\resizebox{20 cm}{!}{\includegraphics{filter_fig}}}
\title{hello}
\end{picture}

\vspace{40pt}
The widget alert process begins with historical data which 
is used to build contract parameter files.  These parameter files are 
then used when data is is received no the DDE link in real time for filtering \& cleaning. 




\newpage
{\large\bf Building Contract Parameters}\\ 
Initial scrubbing involves removing non-positive data from the nuts/bolts as well as any extreme outliers.
Afterward, for each specific test (threshold, fluctuation, etc..), we assume a certain percent of the ticks 
will fail the test.  This allows us to back out an appropriate parameter for that test under the given assumption. 


{\normalsize \bf Threshold Example Calculation} 
{\small
\begin{itemize}
\item Let $\{P^{last}_i\}_{i=1}^n$  be the vector of prices (lasts) sorted by {\it date} after initial scrubbing.
\item Let $\{\Delta P^{last}_j\}_{j=1}^n$  be the vector of price changes sorted by {\it magnitude}.
\item $b_{last}$ - ``bad last'', the percentage of last ticks we assume to be bad.
 \item $k := \lfloor n(1-b_{last})\rfloor$ and then $T_{last} = m\Delta P_k$ where $m$ is a multiplicative factor
and $T_{last}$ is the final threshold parameter stored in the contract parameter file.  
\item In the current code, $b_{last} = .4\%$ (for nuts/bolts) and $m = 2.0$.
\end{itemize}}

\newpage 

{\normalsize \bf Looseness Example Calculation} 
{\small
\begin{itemize}
\item Let $\{P^{last}_i\}_{i=1}^{n_1}$, $\{P^{bid}_i\}_{i=1}^{n_2}$, and $\{P^{ask}_i\}_{i=1}^{n_3}$ be the historical
sequence of lasts, bids, and asks respectively.  
\item $S_t :=  P^{ask}_{\ell} - P^{bid}_{j}$ defines the spread at time $t$ if $\ell$ and $j$ index
the most recent ask/bid prior to time $t$.
\item $\bar{S} := \mbox{median}\{S_t : S_t \not= 0\}$  is our median (positive) spread.
\item $\{S_i\}_{i=1}^{n_4}$ is sequence of positive spreads sorted by magnitude.
\item $k := \lfloor (1 - b_{ask} - b_{bid}n_4)\rfloor$ and then $L_{spread} = m\frac{S_k}{\bar{S}}$
\item In the current code, $b_{ask} = b_{bid} = .8\%$.
\item In realtime if a new bid/ask causes the current spread to exceed the median spread times $L_{spread}$, 
then the new tick is flagged as being bad.   
\end{itemize}
}



\newpage
{\large\bf Pros}
{\small
\begin{enumerate}
\item Everything is fully automated and contract specific.  A threshold test for a price change will be different
for 'CLU06' and 'CLV06'.  
\item Easy black-box testing where if too many ticks are being flagged as bad, can simply decrease
$b_{last}$ or increase $m$.  
\item Parameter files can be edited by hand for specific contracts.  
\item Median calculations (for spreads/fluctuations/slippage) are done offline and then stored in the parameter files. 
(really speeds up cleaning data in realtime).
\end{enumerate}
}

{\large\bf Cons}
{\small
\begin{enumerate}
\item Parameter files need to be built each day reflecting most recent market data.  For the number of 
open positions we typically have, this is around 1-2 hrs. (Can shorten this by looking at less data).
\item If the historical data we build the parameters on is unlike the realtime data, then filtering results
can be incorrect.
\item Not very robust to wrong assumptions about bad percentages.
\end{enumerate}
}

\newpage
{\large\bf Building Widget Prices}\\
{\small When bid/ask/last data is recieved for a nut/bolt, it is passed through a filter consisting 
of a sequence of checks.  If it passes all these checks then we build the estimated widget price.  
Basically the widget is the difference between the nut and the bolt at time $t$, except for the nut/bolt
used can either be the last data or the average of the bid/ask data whichever is more recent. Afterward
$W_t$ is passed through its own filter.} 

{\small
\begin{eqnarray*}
W_t &=& B_t - N_t \\
B_t &=& B^{last}_t \ \ or \ \ \frac{1}{2}\left(B^{bid}_t + B^{ask}_t\right)\\
N_t &=& N^{last}_t \ \ or \ \ \frac{1}{2}\left(N^{bid}_t + N^{ask}_t\right)\\
\end{eqnarray*}}
\begin{picture}(100,100)(0,0)           %% Slides use just picture environment
\put(-50,-60){\resizebox{20 cm}{!}{\includegraphics{figgy}}}
\title{hello}
\end{picture}
\newpage
{\large\bf Some Side Notes}\\
{\small
\begin{enumerate}
\item Estimated widget prices can combine bid/ask data on a nut with last data on a bolt.
\item We only combine bid/ask data for a nut/bolt outside of pit sessions, and when the bid/ask data 
is similar to one another in both time and space.
\item The moving median calculation weights actual widget trades twice as much as widget estimates.  Only 
``fresh'' (last 4 minutes) estimates go into median calculation.  
\item If the moving median drops below a sell stop, or rises above a buy stop an alert is triggered every two 
minutes as long as the condition is true.
\item Widget trades can bypass the moving median calculation and trigger an alert as well.
\end{enumerate}

}

\newpage
{\large\bf Initial Results}\\
{\normalsize 
It's tough to calculate accuracy percentages.  There's no labeled data sets with the ``truth'' for each tick.
Instead we look at the number of alerts triggered and look at those on a case by case basis to 
see if they were valid.\\

Since 8/11/06   
{\small
\begin{itemize}
\item Future Source - triggered 33 alerts, 12 of which were good so about 36\% accurate.
\item Widget Alerts - triggered 20 alerts, 14 of which were good so about 70\% accurate.
\footnote{\it Here we are not counting repeated alerts.}   
\end{itemize}
}

However, the widget alert algorithm has evolved during the testing phase and around half of this
data is concentrated on a few (2-3) active days.    

\newpage
% want to add a GUI picture as well as a pic of the widget_results for some contract.....
\begin{picture}(100,200)(0,0)           %% Slides use just picture environment
\put(-50,-100){\resizebox{18 cm}{!}{\includegraphics{gui_screenshot}}}
\end{picture}

\vspace{80pt}

{\normalsize\bf New \& Improved GUI!}
{\small
\begin{itemize}
\item Allows the trader to select which contracts are currently active!
\item Choose buy and sell stop levels at your convenience!  Automaically saves settings 
next time the program is loaded!
\item Shows current estimated widget prices as well as widget trades!
\item Trader can choose what message he/she would like to see when alert is triggered!
%\item Call now at 1-800-JEMoody and we'll throw in a GI Joe Commando with kung-fu grip action!
\end{itemize}
%}

\newpage
\begin{picture}(100,200)(0,0)           %% Slides use just picture environment
\put(-50,-100){\resizebox{20 cm}{!}{\includegraphics{clv6clx6}}}
\end{picture}

\vspace{80pt}

{\normalsize\bf View Widget Prices Live!}

\newpage
{\large\bf Data Collection} - Consists of:
{\small 
\begin{itemize} \itemsep -2pt
\item Building all the contract symbols we care about.

{\tiny
\begin{itemize} \itemsep 0pt
\item First we programtically generate all possible widgets we are interested in. Current rule: for each symbol, 
choose a starting month as the nut.   Then for symbols with irregular contract cycles listen for the next 
4 possible widgets in the contract cycle starting with that nut.  For symbols with regular contract cycles 
(every month) listen for the 1,2,3,6 mo widgets.
\item The above is done for every possible starting month as the nut between now and the next 5 months.  
\item Once the widgets are generated, then build the individual nuts/bolts by tearing apart the widgets taking
care to generate the mappings for nuts \& bolts that have them. (e.g. 'CL' maps to 'WS', 'QM').  
Currently 31 symbols, 430 widgets, and 394 nuts \& bolts.
\end{itemize}}

{\small \item Adding all the fields we care about to the DDE link for each contract}
{\tiny
\begin{itemize} \itemsep 0pt
\item For nuts/bolts we listen to 6 fields - the bid/ask/last prices and bid/ask/last sizes.
\item For widgets we only listen to 2 fields - the last prices and last sizes.
\item All together that's 394*6 + 430*2 = 3,224 total fields.  
\end{itemize}}

{\small \item Logging all the data to Liffe.}
{\tiny
\begin{itemize}\itemsep 0pt
\item Everything stored to {\tt /liffe/derek/incoming\_data/} where data is stored as {\tt contract\_field.txt} 
(e.g. 'CLV06\_Ask.txt').  We log the time the system recieved the data and its value.
\item Since the beginning of the summer, we've logged 3+GB of data, slightly more than the estimated 1GB per month.
\end{itemize}}

\end{itemize}}

\newpage
{\large\bf Historical Downloads} - Involves:
{\small
\begin{enumerate} \itemsep 0pt
\item Listening the last fields for each contract (only data Future Source(FS) has available).  Max records 
one can download from FS is 10K.  If the number of lasts since last download exceeds 8K then trigger 
an intradaily download for all contracts with number of lasts greater than .75*(8K).
\item Every 10 minutes logging the current state of the system so it loads with correct data after down time.
\item Generates a download symbol list consisting of all contracts that should be downloaded.
\item Kicks off a VB script that reads the symbol list and automates the keystrokes to future source for a historical
download of those symbols.  Writes to a verifcation file when done.
\item Set off a timer that has a callback to read the verifaction file for failed symbols.  
\item Intradaily downloads only concern Tick data.  The daily downloads retrieves 1 minute bars, tick data, and 
daily data.  
\item Cron job runs nightly to re-format and merge the downloaded FS data into the pre-existing files stored 
in {\tt bulldata2}.   
\end{enumerate}
}

\newpage
{\normalsize\bf Sizing up Automating Historical Downloads...}\\
{\small\bf The Good}
{\small 
\begin{itemize} \itemsep 0pt
\item This process gathers the data for us with minimal human intervention.
\item Managed to collect around 1GB of data this way sitting in {\tt bulldata2}.  
\end{itemize}
}
{\small\bf The Bad}
\begin{itemize} \itemsep 0pt
\item Since migrating from {\tt liffe} to {\tt simex}, adding more symbols, and then using a partially connected
FS link, a daily download takes 6+ hours.   
\item Because of the bad connections and slow machines, most downloads fail due to timeouts.  Not so much of a problem
for 1 Min \& Daily data, but this is an issue with with the Tick data.
\end{itemize}
{\small\bf The Ugly}
\begin{itemize} \itemsep 0pt
\item Scripting at the user level is not at all robust, 
\item Takes hours simply just to load the program on {\tt simex}.
\item Interference with short-cut keys \& caps locks, user refocusing, awaking the computer from deep sleep, 
activating applications, errors in timing between sending keystrokes, scripting/permission errors, etc...
\end{itemize}

\newpage
{\large\bf Reality}\\

If we really want a complete data set with no gaps consider dedicating a machine that meets the 
minimum FS requirements and an extra FS seat (w/ delayed data).

\newpage
{\normalsize\bf Transaction Costs} can be divided into calculating the bid/ask spread for 
widgets and calculating the price slippage for widgets.

{\small\bf Widget Bid/Ask Spread}
\begin{enumerate} \itemsep 0pt
\item The bid/ask spread is estimated for a widget, however not for a {\it specific} contract but a particular
underlying with $n$ number of months between the nut/bolt at a time $m$ months prior to the front month.  
\item Here we use the historical tick data downloaded from FS looking at all the contracts that satisfy 
a set of parameters.
\item The data is divided into 30 minute ``chunks'' where for each chunk we look
at the non-zero price changes within that time interval.  The median of these is the 
chunk estimate of the bid/ask spread.
\item The median of all the different chunk medians is returned as an estimate of the bid/ask spread.
\end{enumerate}
Consider...natural gas 'NG' $m$ months prior to the front months for widgets of length $n$.\\
%\begin{table}[h!b]
%\centering
\begin{center}
\begin{tabular}{|l|c|c|c|}
\hline
$m$ & \multicolumn{3}{|c|}{$n$}\\
\hline
& 1 & 2 & 3\\
\hline
1  & 0.003 & 0.0067 & 0.0075\\
2 & 0.0085 & 0.0075 & 0.01\\
3 & 0.01 & 0.01 & NaN\\
\hline
\end{tabular}
%\end{table}
\end{center}

But really only good data for $m,n \leq 2$ in general.

\newpage
{\small\bf Calculating Slippage} is more difficult than the bid/ask spread.  Slippage is the amount the price
changes in the small interval between when one wants to enter a contract, and when the trade finally gets executed.}

{\small
\begin{itemize} \itemsep 0pt
\item In order to estimate this we invariably need to divide the data into smaller chunks, say 1 or 2 minutes.
The problem is that there is very few widget trades to begin with, and finding 1 or 2 minute intervals with
more than one trade is difficult for a lot of contracts.
\item Even if the data {\it were} there, if we were to again look at the non-zero price changes within that small 
interval it would be calculating both the slippage {\it as well} as the bid/ask spread.  
\item That is, if the data were there the same approach as before would yield price slippage estiamtes that 
are biased upward.     
\end{itemize}
}
\newpage
\begin{picture}(300,220)(0,0)           %% Slides use just picture environment
\put(-20,20){\resizebox{20 cm}{!}{\includegraphics{3dpdf}}}
\end{picture}

{\color{blue}
For more details see
{\small \htmladdnormallink{artex.pdf}{artex.pdf}}    %% Link to artex.pdf
}

{\color{red}
{\bf Theorem }\\
$M$ complete, connected, simply-connected\\
$\exists$ naturally reductive homogeneous structure\\
$\Leftrightarrow T_{XYZ}+T_{YXZ}=0 \hspace{1in}\forall X,Y,Z \in {\cal M }$

{\bf Theorem }\\
$T=D-\nabla$ is naturally reductive\\
$\Leftrightarrow \nabla R=0.$
}





\end{document}
