Revolutions

Quantitative Finance applications in R - 8

The latest in a series by Daniel Hanson

Introduction

Correlations between holdings in a portfolio are of course a key component in financial risk management. Borrowing a tool common in fields such as bioinformatics and genetics, we will look at how to use heat maps in R for visualizing correlations among financial returns, and examine behavior in both a stable and down market.

While base R contains its own heatmap(.) function, the reader will likely find the heatmap.2(.) function in the R package gplots to be a bit more user friendly.  A very nicely written companion article entitled A short tutorial for decent heat maps in R (Sebastian Raschka, 2013), which covers more details and features, is available on the web; we will also refer to it in the discussion below.

We will present the topic in the form of an example.

Sample Data

As in previous articles, we will make use of R packages Quandl and xts to acquire and manage our market data.  Here, in a simple example, we will use returns from the following global equity indices over the period 1998-01-05 to the present, and then examine correlations between them:

S&P 500 (US)
RUSSELL 2000 (US Small Cap)
NIKKEI (Japan)
HANG SENG (Hong Kong)
DAX (Germany)
CAC (France)
KOSPI (Korea)

First, we gather the index values and convert to returns:

library(xts)
library(Quandl)
 
my_start_date <- "1998-01-05"
SP500.Q <- Quandl("YAHOO/INDEX_GSPC", start_date = my_start_date, type = "xts")
RUSS2000.Q <- Quandl("YAHOO/INDEX_RUT", start_date = my_start_date, type = "xts")   
NIKKEI.Q <- Quandl("NIKKEI/INDEX", start_date = my_start_date, type = "xts") 
HANG_SENG.Q <- Quandl("YAHOO/INDEX_HSI", start_date = my_start_date, type = "xts") 
DAX.Q <- Quandl("YAHOO/INDEX_GDAXI", start_date = my_start_date, type = "xts") 
CAC.Q <- Quandl("YAHOO/INDEX_FCHI", start_date = my_start_date, type = "xts") 
KOSPI.Q <- Quandl("YAHOO/INDEX_KS11", start_date = my_start_date, type = "xts")   
 
# Depending on the index, the final price for each day is either 
# "Adjusted Close" or "Close Price".  Extract this single column for each:
SP500 <- SP500.Q[,"Adjusted Close"]
RUSS2000 <- RUSS2000.Q[,"Adjusted Close"]
DAX <- DAX.Q[,"Adjusted Close"]
CAC <- CAC.Q[,"Adjusted Close"]
KOSPI <- KOSPI.Q[,"Adjusted Close"]
NIKKEI <- NIKKEI.Q[,"Close Price"]
HANG_SENG <- HANG_SENG.Q[,"Adjusted Close"]
 
# The xts merge(.) function will only accept two series at a time.
# We can, however, merge multiple columns by downcasting to *zoo* objects.
# Remark:  "all = FALSE" uses an inner join to merge the data.
z <- merge(as.zoo(SP500), as.zoo(RUSS2000), as.zoo(DAX), as.zoo(CAC), 
           as.zoo(KOSPI), as.zoo(NIKKEI), as.zoo(HANG_SENG), all = FALSE)   
 
# Set the column names; these will be used in the heat maps:
myColnames <- c("SP500","RUSS2000","DAX","CAC","KOSPI","NIKKEI","HANG_SENG")
colnames(z) <- myColnames
 
# Cast back to an xts object:
mktPrices <- as.xts(z)
 
# Next, calculate log returns:
mktRtns <- diff(log(mktPrices), lag = 1)
head(mktRtns)
mktRtns <- mktRtns[-1, ]  # Remove resulting NA in the 1st row

Generate Heat Maps

As noted above, heatmap.2(.) is the function in the gplots package that we will use.  For convenience, we’ll wrap this function inside our own generate_heat_map(.) function, as we will call this parameterization several times to compare market conditions.

As for the parameterization, the comments should be self-explanatory, but we’re keeping things simple by eliminating the dendogram, and leaving out the trace lines inside the heat map and density plot inside the color legend.  Note also the setting Rowv = FALSE, this ensures the ordering of the rows and columns remains consistent from plot to plot.  We’re also just using the default color settings; for customized colors, see the Raschka tutorial linked above.

require(gplots)
 
generate_heat_map <- function(correlationMatrix, title)
{
 
  heatmap.2(x = correlationMatrix,		# the correlation matrix input
            cellnote = correlationMatrix	# places correlation value in each cell
            main = title,			# heat map title
            symm = TRUE,			# configure diagram as standard correlation matrix
            dendrogram="none",		# do not draw a row dendrogram
            Rowv = FALSE,			# keep ordering consistent
            trace="none",			# turns off trace lines inside the heat map
            density.info="none",		# turns off density plot inside color legend
            notecol="black")		# set font color of cell labels to black
 
}

Next, let’s calculate three correlation matrices using the data we have obtained:

• Correlations based on the entire data set from 1998-01-05 to the present
• Correlations of market indices during a reasonably calm period -- January through December 2004
• Correlations of falling market indices in the midst of the financial crisis - October 2008 through May 2009

# Convert each to percent format
corr1 <- cor(mktRtns) * 100
corr2 <- cor(mktRtns['2004-01/2004-12']) * 100
corr3 <- cor(mktRtns['2008-10/2009-05']) * 100

Now, let’s call our heat map function using the total market data set:

generate_heat_map(corr1, "Correlations of World Market Returns, Jan 1998 - Present")

And then, examine the result:

 

As expected, we trivially have correlations of 100% down the main diagonal.  Note that, as shown in the color key, the darker the color, the lower the correlation.  By design, using the parameters of the heatmap.2(.) function, we set the title with the main = title parameter setting, and the correlations shown in black by using the notecol="black" setting.     

Next, let’s look at a period of relative calm in the markets, namely the year 2004:

generate_heat_map(corr2, "Correlations of World Market Returns, Jan - Dec 2004")

This gives us:

generate_heat_map(corr2, "Correlations of World Market Returns, Jan - Dec 2004")

Note that in this case, at a glance of the darker colors in each of the cells, we can see that we have even lower correlations than those from our entire data set.  This may of course be verified by comparing the numerical values.

Finally, let’s look at the opposite extreme, during the upheaval of the financial crisis in 2008-2009:

generate_heat_map(corr3, "Correlations of World Market Returns, Oct 2008 - May 2009")

This yields the following heat map:

 

Note that in this case, again just at first glance, we can tell the correlations have increased compared to 2004, by the colors changing from dark to light nearly across the board.  While there are some correlations that do not increase all that much, such as the SP500/Nikkei and the Russell 2000/Kospi values, there are others across international and capitalization categories that jump quite significantly, such as the SP500/Hang Seng correlation going from about 21% to 41%, and that of the Russell 2000/DAX moving from 43% to over 57%.  So, in other words, portfolio diversification can take a hit in down markets.  

Conclusion

In this example, we only looked at seven market indices, but for a closer look at how correlations were affected during 2008-09 -- and how heat maps among a greater number of market sectors compared -- this article, entitled Diversification is Broken, is a recommended and interesting read.

Agent Based Models and RNetLogo

by Joseph Rickert

If I had to pick just one application to be the “killer app” for the digital computer I would probably choose Agent Based Modeling (ABM). Imagine creating a world populated with hundreds, or even thousands of agents, interacting with each other and with the environment according to their own simple rules. What kinds of patterns and behaviors would emerge if you just let the simulation run? Could you guess a set of rules that would mimic some part of the real world? This dream is probably much older than the digital computer, but according to Jan Thiele’s brief account of the history of ABMs that begins his recent paper, R Marries NetLogo: Introduction to the RNetLogo Package in the Journal of Statistical Software, academic work with ABMs didn’t really take off until the late 1990s.

Now, people are using ABMs for serious studies in economics, sociology, ecology, socio-psychology, anthropology, marketing and many other fields. No less of a complexity scientist than Doyne Farmer (of Dynamic Systems and Prediction Company fame) has argued in Nature for using ABMs to model the complexity of the US economy, and has published on using ABMs to drive investment models. in the following clip of a  2006 interview, Doyne talks about building ABMs to explain the role of subprime mortgages on the Housing Crisis. (Note that when asked about how one would calibrate such a model Doyne explains the need to collect massive amounts of data on individuals.)

 

Fortunately, the tools for building ABMs seem to be keeping pace with the ambition of the modelers. There are now dozens of platforms for building ABMs, and it is somewhat surprising that NetLogo, a tool with some whimsical terminology (e.g. agents are called turtles) that was designed for teaching children, has apparently become a defacto standard. NetLogo is Java based, has an intuitive GUI, ships with dozens of useful sample models, is easy to program, and is available under the GPL 2 license.

As you might expect, R is a perfect complement for NetLogo. Doing serious simulation work requires a considerable amount of statistics for calibrating models, designing experiments, performing sensitivity analyses, reducing data, exploring the results of simulation runs and much more. The recent JASS paper Facilitating Parameter Estimation and Sensitivity Analysis of Agent-Based Models: a Cookbook Using NetLogo and R by Thiele and his collaborators describe the R / NetLogo relationship in great detail and points to a decade’s worth of reading. But the real fun is that Thiele’s RNetLogo package lets you jump in and start analyzing NetLogo models in a matter of minutes.

Here is part of an extended example from Thiele's JSS paper that shows R interacting with the Fire model that ships with NetLogo. Using some very simple logic, Fire models the progress of a forest fire. 

Snippet of NetLogo Code that drives the Fire model

to go
  if not any? turtles  ;; either fires or embers
    [ stop ]
  ask fires
    [ ask neighbors4 with [pcolor = green]
        [ ignite ]
      set breed embers ]
  fade-embers
  tick
end
 
;; creates the fire turtles
to ignite  ;; patch procedure
  sprout-fires 1
    [ set color red ]
  set pcolor black
  set burned-trees burned-trees + 1
end

The general idea is that turtles represent the frontier of the fire run through a grid of randomly placed trees. Not shown in the above snippet is the logic that shows that the entire model is controlled by a single parameter representing the density of the trees. 

This next bit of R code shows how to launch the Fire model from R, set the density parameter, and run the model.

# Launch RNetLogo and control an initial run of the
# NetLogo Fire Model
library(RNetLogo)
nlDir <- "C:/Program Files (x86)/NetLogo 5.0.5"
setwd(nlDir)
 
nl.path <- getwd()
NLStart(nl.path)
 
model.path <- file.path("models", "Sample Models", "Earth Science","Fire.nlogo")
NLLoadModel(file.path(nl.path, model.path))
 
NLCommand("set density 70")    # set density value
NLCommand("setup")             # call the setup routine 
NLCommand("go")                # launch the model from R

Here we see the Fire model running  in the NetLogo GUI after it was launched from RStudio.

This next bit of code tracks the progression of the fire as a function of time (model "ticks"), returns results to R and plots them. The plot shows the non-linear behavior of the system. 

# Investigate percentage of forest burned as simulation proceeds and plot
library(ggplot2)
NLCommand("set density 60")
NLCommand("setup")
burned <- NLDoReportWhile("any? turtles", "go",
                c("ticks", "(burned-trees / initial-trees) * 100"),
                as.data.frame = TRUE, df.col.names = c("tick", "percent.burned"))
# Plot with ggplot2
p <- ggplot(burned,aes(x=tick,y=percent.burned))
p + geom_line() + ggtitle("Non-linear forest fire progression with density = 60")

As with many dynamical systems, the Fire model displays a phase transition. Setting the density lower than 55 will not result in the complete destruction of the forest, while setting density above 75 will very likely result in complete destruction. The following plot shows this behavior.

 

RNetLogo makes it very easy to programatically run multiple simulations and capture the results for analysis in R. The following two lines of code runs the Fire model twenty times for each value of density between 55 and 65, the region surrounding the pahse transition.

d <- seq(55, 65, 1)                  # vector of densities to examine
res <- rep.sim(d, 20)                # Run the simulation

The plot below shows the variability of the percent of trees burned as a function of density in the transition region.

 

My code to generate plots is available in the file:  Download NelLogo_blog while all of the code from Thiele's JSS paper is available from the journal website.

Finally, here are a few more interesting links related to ABMs.

• On validating ABMs
• ABMs and
• Financial Markets
• Computational Finance
• Infectious Diseases
• Macroeconomic modeling
• Social Science

 

Quantitative Finance applications in R - 7: Constructing a Term Structure of Interest Rates Using R (part 2 of 2)

by Daniel Hanson

Recap and Introduction

Last time in part 1 of this topic, we used the xts and lubridate packages to interpolate a zero rate for every date over the span of 30 years of market yield curve data.  In this article, we will look at how we can implement the two essential functions of a term structure:  the forward interest rate, and the forward discount factor.

Definitions and Notation
We will apply a mix of notation adopted in the lecture notes Interest Rate Models: Introduction, pp 3-4, from the New York University Courant Institute (2005), along with chapter 1 of the book Interest Rate Models — Theory and Practice (2nd edition, Brigo and Mercurio, 2006).  A presentation by Damiano Brigo from 2007, which covers some of the essential background found in the book, is available here, from the Columbia University website.

First, t ≧ 0 and T ≧ 0 represent time values in years.

P(t, T) represents the forward discount factor at time t ≦ T, where T ≦ 30 years (in our case), as seen at time = 0 (ie, our anchor date).  In other words, again in US Dollar parlance, this means the value at time t of one dollar to be received at time T, based on continuously compounded interest.  Note then that, trivially, we must have P(T, T) = 1.

R(t, T) represents the continuously compounded forward interest rate, as seen at time = 0, paid over the period [t, T].  This is also sometimes written as F(0; t, T) to indicate that this is the forward rate as seen at the anchor date (time = 0), but to keep the notation lighter, we will use R(t, T) as is done in the NYU notes.

We then have the following relationships between P(t, T) and R(t, T), based on the properties of continuously compounded interest:

P(t, T) = exp(-R(t, T)・(T - t)) (A)

R(t, T) = -log(P(t, T)) / (T - t) (B)

Finally, the interpolated the market yield curve we constructed last time allows us to find the value of R(0, T) for any T ≦ 30.  Then, since by properties of the exponential function we have

P(t, T) = P(0, T) / P(0, t) (C)

we can determine any discount factor P(t, T) for 0 ≦ t ≦ T ≦ 30, and therefore any R(t, T), as seen at time = 0.

Converting from Dates to Year Fractions
By now, one might be wondering -- when we constructed our interpolated market yield curve, we used actual dates, but here, we’re talking about time in units of years -- what’s up with that?  The answer is that we need to convert from dates to year fractions.  While this may seem like a rather trivial proposition -- for example, why not just divide the number of days between the start date and maturity date by 365.25 -- it turns out that, with financial instruments such as bonds, options, and futures, in practice we need to be much more careful.  Each of these comes with a specified day count convention, and if not followed properly, it can result in the loss of millions for a trading desk.

For example, consider the Actual / 365 Fixed day count convention:

            Year Fraction (ie, T - t) = (Days between Date1 and Date2) / 365

This is one commonly used convention and is very simple to calculate; however, for certain bond calculations, it can become much more complicated, as leap years are considered, as well as local holidays in the country in which the bond is traded, plus more esoteric conditions that may be imposed. To get an idea, look up day count conventions used for government bonds in various countries.  

In the book by Brigo and Mercurio noted above, the authors in fact replace the “T - t” expression with a function (tau) τ(t, T), which represents the difference in time based upon the day count convention in effect.  

Equation (A) then becomes

            P(t, T) = exp(-R(t, T)・ τ(t, T))

where τ(t, T) might be, for example, the Actual / 365 Fixed day count convention.

For the remainder of this article, we will implement to the “T - t” above as a day count function, as demonstrated in the example to follow.

Implementation in R
We will first revisit the example from our previous article on interpolation of market zero rates, and then use this to demonstrate the implementation of term structure functions to calculate forward discount factors and forward interest rates.

a) The setup from part 1

Let’s first go back to the example from part 1 and construct our interpolated 30-year market yield curve, using cubic spline interpolation.  Both the xts and lubridate packages need to be loaded.  The code is republished here for convenience:

require(xts)
require(lubridate)
ad <- ymd(20140514, tz = "US/Pacific")   
marketDates <- c(ad, ad + days(1), ad + weeks(1), ad + months(1),
                 ad + months(2), ad + months(3), ad + months(6),
                 ad + months(9), ad + years(1), ad + years(2),
                 ad + years(3), ad + years(5), ad + years(7),
                 ad + years(10), ad + years(15), ad + years(20),
                 ad + years(25), ad + years(30))

# Use substring(.) to get rid of "UTC"/time zone after the dates
marketDates <- as.Date(substring(marketDates, 1, 10))

# Convert percentage formats to decimal by multiplying by 0.01:   
marketRates <- c(0.0, 0.08, 0.125, 0.15, 0.20, 0.255, 0.35, 0.55, 1.65,
                 2.25, 2.85, 3.10, 3.35, 3.65, 3.95, 4.65, 5.15, 5.85) * 0.01

numRates <- length(marketRates)
marketData.xts <- as.xts(marketRates, order.by = marketDates)
createEmptyTermStructureXtsLub <- function(anchorDate, plusYears)
{  
    # anchorDate is a lubridate here:
    endDate <- anchorDate + years(plusYears)
    numDays <- endDate - anchorDate  
    # We need to convert anchorDate to a standard R date to use
    # the "+ 0:numDays" operation
    # Also, note that we need a total of numDays + 1
    # in order to capture both end points.

     xts.termStruct <- xts(rep(NA, numDays + 1),
                       as.Date(anchorDate) + 0:numDays)
     return(xts.termStruct)  
}

termStruct <- createEmptyTermStructureXtsLub(ad, 30)

for(i in (1:numRates)) termStruct[marketDates[i]] <-
              marketData.xts[marketDates[i]]

termStruct.spline.interpolate <- na.spline(termStruct, method = "hyman")
colnames(termStruct.spline.interpolate) <- "ZeroRate"

b) Check the plot

plot(x = termStruct.spline.interpolate[, "ZeroRate"], xlab = "Time",
             ylab = "Zero Rate",
             main = "Interpolated Market Zero Rates 2014-05-14 -
                     Cubic Spline Interpolation",
             ylim = c(0.0, 0.06), major.ticks= "years",
             minor.ticks = FALSE, col = "darkblue")

This gives us a reasonably smooth curve, preserving the monotonicity of our data points:

c) Implement functions for discount factors and forward rates

We will now implement these functions, utilizing equations (A), (B), and (C) above.  We will also take advantage of the functional programming feature in R, by incorporating the Actual / 365 Fixed day count as a functional argument, as an example.  One could of course implement any other day count convention as a function of two lubridate dates, and pass it in as an argument.

First, let’s implement the Actual / 365 Fixed day count as a function:

# Simple example of a day count function: Actual / 365 Fixed
# date1 and date2 are assumed to be lubridate dates, so that we can
# easily carry out the subtraction of two dates.
dayCountFcn_Act365F <- function(date1, date2)
{
    yearFraction <- as.numeric((date2 - date1)/365)
    return(yearFraction)  
}

Next, since the forward rate R(t, T) depends on the forward discount factor P(t, T), let’s implement the latter first:

# date1 and date2 are again assumed to be lubridate dates.

fwdDiscountFactor <- function(anchorDate, date1, date2, xtsMarketData, dayCountFunction)
{  
    # Convert lubridate dates to base R dates in order to use as xts indices.
    xtsDate1 <- as.Date(date1)
    xtsDate2 <- as.Date(date2)   
    if((xtsDate1 > xtsDate2) | xtsDate2 > max(index(xtsMarketData)) |
         xtsDate1 < min(index(xtsMarketData)))
         {
            stop("Error in date order or range")    
         }

    # 1st, get the corresponding market zero rates from our
    # interpolated market rate curve:

    rate1 <- as.numeric(xtsMarketData[xtsDate1])      # R(0, T1)
    rate2 <- as.numeric(xtsMarketData[xtsDate2])      # R(0, T2)
    # P(0, T) = exp(-R(0, T) * (T - 0))   (A), with t = 0 <=> anchorDate  
    discFactor1 <- exp(-rate1 * dayCountFunction(anchorDate, date1))
    discFactor2 <- exp(-rate2 * dayCountFunction(anchorDate, date2))

    # P(t, T) = P(0, T) / P(0, t)  (C), with t <=> date1 and T <=> date2
    fwdDF <- discFactor2/discFactor1

 return(fwdDF)  
}

Finally, we can then write a function to compute the forward interest rate:

# date1 and date2 are assumed to be lubridate dates here as well.
fwdInterestRate <- function(anchorDate, date1, date2, xtsMarketData, dayCountFunction)
{
     if(date1 == date2) {
        fwdRate = 0.0 # the trivial case
     } else { 
           fwdDF <- fwdDiscountFactor(anchorDate, date1, date2,
                               xtsMarketData, dayCountFunction)

           # R(t, T) = -log(P(t, T)) / (T - t)    (B)  
           fwdRate <- -log(fwdDF)/dayCountFunction(date1, date2)
            }
        return(fwdRate)  
}

d) Calculate discount factors and forward interest rates

As an example, suppose we want to get the five year forward three-month discount factor and interest rates:

# Five year forward 3-month discount factor and forward rate:
date1 <- anchorDate + years(5)
date2 <- date1 + months(3)
fwdDiscountFactor(anchorDate, date1, date2, termStruct.spline.interpolate,
                  dayCountFcn_Act365F)

fwdInterestRate(anchorDate, date1, date2, termStruct.spline.interpolate,
                dayCountFcn_Act365F)

# Results are:
# [1] 0.9919104
# [1] 0.03222516

We can also check the trivial case for P(T, T) and R(T, T), where we get 1.0 and 0.0 respectively, as expected:

# Trivial case:
fwdDiscountFactor(anchorDate, date1, date1, termStruct.spline.interpolate,
dayCountFcn_Act365F) # returns 1.0
fwdInterestRate(anchorDate, date1, date1, termStruct.spline.interpolate,
dayCountFcn_Act365F) # returns 0.0

Finally, we can verify that we can recover the market rates at various points along the curve; here, we look at 1Y and 30Y, and can check that we get 0.0165 and 0.0585, respectively:

# Check that we recover market data points:
oneYear <- anchorDate + years(1)
thirtyYears <- anchorDate + years(30)
fwdInterestRate(anchorDate, anchorDate, oneYear,
                termStruct.spline.interpolate,
                dayCountFcn_Act365F)  # returns 1.65%

fwdInterestRate(anchorDate, anchorDate, thirtyYears,
                termStruct.spline.interpolate,
                dayCountFcn_Act365F)  # returns 5.85%

Concluding Remarks

We have shown how one can implement a term structure of interest rates utilizing tools available in the R packages lubridate and xts.  We have, however, limited the example to interpolation within the 30 year range of given market data without discussing extrapolation in cases where forward rates are needed beyond the endpoint.  This case does arise in risk management for longer term financial instruments such as variable annuity and life insurance products, for example.  One simple-minded -- but sometimes used -- method is to fix the zero rate that is given at the endpoint for all dates beyond that point.  A more sophisticated approach is to use the financial cubic spline method as described in the paper by Adams (2001), cited in part 1 of the current discussion.  However, xts unfortunately does not provide this interpolation method for us out of the box.  Writing our own implementation might make for an interesting topic for discussion down the road -- something to keep in mind.  For now, however, we have a working term structure implementation in R that we can use to demonstrate derivatives pricing  and risk management models in upcoming articles.

 

Constructing a Continuous Futures Series From Quandl

by Ilya Kipnis

In this post, I will demonstrate how to obtain, stitch together, and clean data for backtesting using futures data from Quandl. Quandl was previously introduced in the Revolutions Blog.  Functions I will be using can be found in my IK Trading package available on my github page.

With backtesting, it’s often times easy to get data for equities and ETFs. However, ETFs are fairly recent financial instruments, making it difficult to conduct long-running backtests (most of the ETFs in inception before 2003 are equity ETFs), and with equities, they are all correlated in some way, shape, or form to their respective index (S&P 500, Russell, etc.), and their correlations generally go to 1 right as you want to be diversified.

An excellent source of diversification is the futures markets, which contain contracts on instruments ranging as far and wide as metals, forex, energies, and more. Unfortunately, futures are not continuous in nature, and data for futures are harder to find.

Thanks to Quandl, however, there is some freely available futures data. The link can be found here. 

The way Quandl structures its futures is that it uses two separate time series: the first is the front month, which is the contract nearest expiry, and the second is the back month, which is the next contract. Quandl’s rolling algorithm can be found here.

In short, Quandl rolls in a very simple manner; however, it is also incorrect, for all practical purposes. The reason being is that no practical trader holds a contract to expiry. Instead, they roll said contracts sometime before the expiry of the front month, based on some metric.

This algorithm uses the open interest cross to roll from front to back month and then lags that by a day (since open interest is observed at the end of trading days), and then “rolls” back when the front month open interest overtakes back month open interest (in reality, this is the back month contract becoming the new front month contract). Furthermore, the algorithm does absolutely no adjusting to contract prices. That is, if the front month is more expensive than the back month, a long position would lose the roll premium and a short position would gain it. This is in order to prevent the introduction of a dominating trend bias. The reason that the open interest is chosen is displayed in the following graph:

This is the graph of the open interest of the front month of oil in 2000 (black time series), and the open interest of the back month contract in red. They cross under and over in repeatable fashion, making a good choice on when to roll the contract.
Let’s look at the code:

quandClean <- function(stemCode, start_date=NULL, verbose=FALSE, ...) {

The arguments to the function are a stem code, a start date, end date, and two print arguments (for debugging purposes). The stem code takes the form of CHRIS/<<EXCHANGE>>_<<CONTRACT STEM>>, such as “CHRIS/CME_CL” for oil.

Require(Quandl)
if(is.null(start_date)) {start_date <- Sys.Date()-365*1000}
if(is.null(end_date)) {end_date <- Sys.Date()+365*1000}
frontCode <- paste0(stemCode, 1)
backCode <- paste0(stemCode, 2)
front <- Quandl(frontCode, type="xts", start_date=start_date, end_date=end_date, ...)
interestColname <- colnames(front)[grep(pattern="Interest", colnames(front))]
front <- front[,c("Open","High","Low","Settle","Volume",interestColname)]
colnames(front) <- c("O","H","L","C","V","OI")
back <- Quandl(backCode, type="xts", start_date=start_date, end_date=end_date, ...)
back <- back[,c("Open","High","Low","Settle","Volume",interestColname)]
colnames(back) <- c("BO","BH","BL","BS","BV","BI") #B for Back

#combine front and back for comparison
both <- cbind(front,back)

This code simply fetches both futures contracts from Quandl and combines them into one xts. Although Quandl takes a type argument, I have programmed this function specifically for xts types of objects, since I will use xts-dependent functionality later.
Let's move along.

#impute NAs in open interest with -1
both$BI[is.na(both$BI)] <- -1
both$OI[is.na(both$OI)] <- -1
both$lagBI <- lag(both$BI)
both$lagOI <- lag(both$OI)

#impute bad back month open-interest prints --
#if it is truly a low quantity, it won't make a
#difference in the computation.
both$OI[both$OI==-1] <- both$lagOI[both$OI==-1]
both$BI[both$BI==-1] <- both$lagBI[both$BI==-1]

This is the first instance of countermeasures in the function taken to counteract messy data. This imputes any open interest NAs with the value -1, and then imputing the first NA after a non NA day with the previous day's open interest. Usually, days on which open interest is not available are days after which the contract is lightly traded, so the values that will be imputed in cases during which the contract was not traded will be negligible. However, imputing an NA value with a zero during the midst of heavy trading has the potential to display the wrong contract as the one with the higher open interest.

both$OIdiff <- both$OI - both$BI
both$tracker <- NA

#the formal open interest cross from front to back
both$tracker[both$OIdiff < 0] <- -1
both$tracker <- lag(both$tracker)

#since we have to observe OI cross, we roll next day
#any time we're not on the back contract, we're on the front contract
both$tracker[both$OIdiff > 0] <- 1
both$tracker <- na.locf(both$tracker)

This code sets up the system for keeping track of which contract is in use. When the difference in open interest crosses under zero, that's the formal open interest cross, and we roll a day later. On the other hand, when the open interest difference crosses back over zero, that isn't a cross. That is the back month contract becoming the front month contract. For instance, assume that you rolled to the June contract in the third week of May. Quandl would display the June contract as the back contract in May, but come June, that June contract is now the front contract instead. So therefore, there is no lag on the computation in the second instance.

frontRelevant <- both[both$tracker==1, c(1:6)]
backRelevant <- both[both$tracker==-1, c(7:12)]
colnames(frontRelevant) <- colnames(backRelevant) <- c("Open","High","Low","Close","Volume","OpenInterest")
relevant <- rbind(frontRelevant, backRelevant)
relevant[relevant==0] <- NA

# remove any incomplete days, print a message saying
# how many removed days
# print them if desired
instrument <- gsub("CHRIS/", "", stemCode)
relevant$Open[is.na(relevant$Open)] <- relevant$Close[(which(is.na(relevant$Open))-1)]
NAs <- which(is.na(relevant$Open) | is.na(relevant$High) | is.na(relevant$Low) | is.na(relevant$Close))
if(verbose) {
if(verbose) { message(paste(instrument, "had", length(NAs), "incomplete days removed from data.")) }

print(relevant[NAs,])
}
if(length(NAs) > 0) {
relevant <- relevant[-NAs,]
}

Using the previous tracker variable, the code is then able to compile the relevant data for the futures contract. That is, front contract when the front contract is more heavily traded, and vice versa.

This code uses xts-dependent functionality with the rbind call. In this instance, there are two separate streams: the front month stream, and the back month stream. Through the use of xts functionality, it's possible to merge the two streams indexed by time.

Next, the code imputes all NA open values with the close (settle) from the previous trading day. In the case that opens are the only missing field, I opted for this over removing the observation entirely. Next, any observation with a missing open, high, low, or close value gets removed. This is simply my personal preference, rather than attempting to take some form of liberty with imputing data to the highs, lows, and closes based on the previous day, or some other pattern thereof.

If verbose is enabled, the function will print the actual data removed.

ATR <- ATR(HLC=HLC(relevant))

#Technically somewhat cheating, but could be stated in terms of
#lag 2, 1,and 0.
#A spike is defined as a data point on Close that's more than
#5 ATRs away from both the preceding and following day.
spikes <- which(abs((relevant$Close-lag(relevant$Close))/ATR$atr) > 5
& abs((relevant$Close-lag(relevant$Close, -1))/ATR$atr) > 5)
if(verbose) {
message(paste(instrument, "had", length(spikes),"spike days removed from data."))
print(relevant[spikes,])
}

if(length(spikes) > 0){
relevant <- relevant[-spikes,]
}
out <- relevant
return(out)
}

Finally, some countermeasures against spiky types of data. I define a spike as a price move in the closing price which is 5 ATRs (in this case, n=14) away in either direction from both the previous and next day. Spikes are removed. After this, the code is complete.

To put this into perspective visually, here is a plot of the 30-day Federal Funds rate (CHRIS/CME_FF), from 2008, demonstrating all the improvements my process makes to Quandl’s raw data in comparison to the front month continuous (current) contract.

The raw, front-month data is displayed in black (the long lines are missing data from quandl, displayed as zeroes, but modified in scale for the sake of the plot). The results of the algorithm are presented in blue.

At the very beginning, it’s apparent that the more intelligent rolling algorithm adapts to what would be the new contract prices sooner. Secondly, all of those long bars on which Quandl had missing data have been removed so as not to interfere with calculations. Lastly, at the very end, that downward “spike” in prices has also been dealt with, making for what appears to be a significantly more correct pricing series.

To summarize, here's what the code does:

1) Downloads the two data streams
2) Keeps track of the proper contract at all time periods
3) Imputes or removes bad data, bad data being defined as incomplete observations or spikes in the data.

The result is an xts object practically identical to one downloaded with more common to find data, such as equities or ETFs, which allows for a greater array of diversification in terms of the instruments on which to backtest trading strategies, such as with the quantstrat package.

The results of such backtests can be found on my blog, and my two R packages (this functionality will be available in my IKTrading package) can be found on my Github page.

Quantitative Finance Applications in R - 6: Constructing a Term Structure of Interest Rates Using R (Part 1)

by Daniel Hanson

Introduction

Last time, we used the discretization of a Brownian Motion process with a Monte Carlo method to simulate the returns of a single security, with the (rather strong) assumption of a fixed drift term and fixed volatility.  We will return to this topic in a future article, as it relates to basic option pricing methods, which we will then expand upon.

For more advanced derivatives pricing methods, however, as well as an important topic in its own right, we will talk about implementing a term structure of interest rates using R.  This will be broken up into two parts:  1) working with dates and interpolation (the subject of today’s article), and 2) calculating forward interest rates and discount factors (the topic of our next article), using the results presented below.

Working with Dates in R

The standard date objects in base R, to be honest, are not the most user-friendly when it comes to basic date calculations such as adding days, months, or years.  For example, just to add, say, five years to a given date, we would need to do the following:

startDate <- as.Date('2014-05-27')
pDate <- as.POSIXlt(startDate)
endDate <- as.Date(paste(pDate$year + 1900 + 5, "-", pDate$mon + 1, "-", pDate$mday, sep = ""))

So, you’re probably asking yourself, “wouldn’t it be great if we could just add the years like this?”:

 endDate <- startDate + years(5)         # ?

Well, the good news is that we can, by using the lubridate package.  In addition, instantiating a date is also easier, simply by indicating the date format (eg ymd(.) for year-mo-day) as the function.  Below are some examples:

require(lubridate)
startDate <- ymd(20140527)
startDate # Result is:  "2014-05-27 UTC"

anotherDate <- dmy(26102013)
anotherDate # Result is:  "2013-10-26 UTC"

startDate + years(5) # Result is:  "2019-05-27 UTC"
anotherDate - years(40) # Result is:  "1973-10-26 UTC"

startDate + days(2) # Result is:  "2014-05-29 UTC"
anotherDate - months(5) # Result is:  "2013-05-26 UTC"

Remark:  Note that “UTC” is appended to the end of each date, which indicates the Coordinated Universal Time time zone (the default).  While it is not an issue in these examples, it will be important to specify a particular time zone when we set up our interpolated yield curve, as we shall see shortly.

Interpolation with Dates in R

When interpolating values in a time series in R, we revisit with our old friend, the xts package, which provides both linear and cubic spline interpolation.　We will demonstrate this with a somewhat realistic example.

 

R / Finance 2014: Packaged Takeaways

by Joseph Rickert

I was very happy to have been able to attend R / Finance 2014 which wrapped up a couple of weeks ago. In general, the talks were at a very high level of play, some dealing with brand new ideas and many presented at a significant level of technical or mathematical sophistication. Fortunately, most of the slides from the presentations are quite detailed and available at the conference site. Collectively, these presentations provide a view of the boundaries of the conceptual space imagined by the leaders in quantitative finance. Some of this space covers infrastructure issues involving ideas for pushing the limits of R (Some Performance Improvements for the R Engine) or building a new infrasturcture (New Ideas for Large Network Analysis) or (Building Simple Data Caches) for example. Others are involved with new computational tools (Solving Cone Constrained Convex Programs) or attempt to push the limits on getting some actionable insight from the mathematical abstrations: (Portfolio Inference withthei One Wierd Trick) or (Twinkle twinkle litle STAR: Smooth Transition AR Models in R) for example.

But while the talks may be illuminating, the real take-aways from the conference are the R packages. These tools embody the work of the thought leaders in the field of computational finance and are the means for anyone sufficiently motivated to understand this cutting edge work.  By my count, 20 of the 44 tutorials and talks given at the conference were based on a particular R package. Some of the packages listed in the following table are well-established and others are work-in-progress sitting out on R-Forge or GitHub, providing opportunities for the interested to get involved.

R Finance 2014 Talk	Package	Description
Introduction to data.table	data.table	Extension of the data frame
An Example-Driven Hands-on introduction to Rcpp	Rcpp	Functions to facilitate integrating R with C++
Portfolio Optimization: Utility, Computation, Equities Applications	fPortfolio	Environment for reaching Financial Engineering and Computational Finance
Re-Evaluation of the Low Risk Anomaly via Matching	cem	Implementation of the Coarsened Exact matching Algorithm
BCP Stability Analytics: New Directions in Tactical Asset Management	bcp	Bayesian Analysis of Change Point Problems
On the Persistence of Cointegration in Pairs Trading	egcm	Engle-Granger Cointegration Models
Tests for Robust Versus Least Squares Factor Model Fits	robust	robust methods
The R Package cccp: Solving Cone Constrained Convex Programs	cccp	Solver for convex problems for cone constraints
Twinkle, twinkle little STAR: Smooth Transition AR Models in R	Twinkle	Modeling smooth transition models
Asset Allocaton with Higher Order Moments and Factor Models	DEoptim /   PortfolioAnalytics	Global optimization by differential evolution / Numerical methods for portfolio optimization
Event Studies in R	eventstudies	Event study and extreme event analysis
An R package on Credit Default Swaps	CDS	Provides tools for pricing credit default swaps
New Ideas for Large Network Analysis, Implemented in R	IRL	Implicitly restarted Lanczos methods for R
Package “Intermediate and Long Memory Time Series	ILMTS	Simulate & Detect Intermediate and Long Memory Processes / in development
Stochvol: Dealing with Stochastic Volatility in Time Series	stochvol	Efficient Bayesian Inference for Stochastic Volatility (SV) Models
Divide and Recombine for the Analysis of Large Complex Data with R	RHIPE	Package for using R with Hadoop
gpusvcalibration: Fast Stochastic Volatility Model Calibration using GPUs	gpusvcalibration	Fast calibration of stochastic volatility models for option pricing models
The FlexBayes Package	FlexBayes	Provides an MCMC engine for the class of hierarchical feneralized linear models and connections to WinBUGS and OpenBUGS
Building Simple Redis Data Caches	RcppReddis	Rcpp bindings for Redis that connects R to the Redis key/value store
Package pbo: Probability of Backtest Overfitting	pbo	Uses Combinatorial Symmetric Cross Validation to implement performance tests.

 

Many of these packages / projects also have supplementary material that is worth chasing down. Be sure to take a look at Alexios Ghalanos recent post that provides an accessible introduction to his stellar keynote address.

Many thanks to the organizers of the conference who, once again, did a superb job, and to the many professionals attending who graciously attempted to explain their ideas to a dilletante. My impression was that most of the attendies thoroughly enjoyed themselves and that the general sentiment was expressed by the last slide of Stephen Rush's presentation:

 

 

R and Finance

by Joseph Rickert

R/Finance 2014 is just about a week away. Over the past four or five years this has become my favorite conference. It is small (300 people this year), exceptionally well-run, and always offers an eclectic mix of theoretical mathematics, efficient, practical computing, industry best practices and trading “street smarts”. This clip of Blair Hull delivering a keynote speech at R/Finance 2012 is an example of the latter. It ought to resonate with anyone who has followed some of the hype surrounding Michael Lewis recent book Flash Boys.

 

In any event, I thought it would be a good time to look at the relationship between R and Finance and to highlight some resources that are available to students, quants and data scientists looking to do computational finance with R.

First off, consider what computational finance has done for R. From the point of view of the development and growth of the R language, I think it is pretty clear that computational finance has played the role of the ultimate “Killer App” for R. This high stakes, competitive environment where a theoretical edge or a marginal computational advantage can mean big rewards has led to R package development in several areas including time series, optimization, portfolio analysis, risk management, high performance computing and big data. Additionally, challenges and crisis in the financial markets have helped accelerate R’s growth into big data. In this podcast, Michael Kane talks about the analysis of the 2010 Flash Crash he did with Casey King  and Richard Holowczak and describes using R with large financial datasets.

Conversely, I think that it is also clear that R has done quite a bit to further computational finance. R’s ability to facilitate rapid data analysis and visualization, its great number of available functions and algorithms and the ease with which it can interface to new data sources and other computing environments has made it a flexible tool that evolves  and adapts at a pace that matches developments in the financial industry. The list of packages in the Finance Task View on CRAN indicates the symbiotic relationship between the development of R and the needs of those working in computational finance. On the one hand, there are over 70 packages under the headings Finance and Risk Management that were presumably developed to directly respond to a problem in computational finance. But, the task view also mentions that packages in the  Econometrics, Multivariate, Optimization, Robust, SocialSciences and TimeSeries task views may also be useful to anyone working in computational finance. (The High Performance Computing and Machine Learning task views should probably also be mentioned.) The point is that while a good bit of R is useful to problems in computational finance, R has greatly benefited from the contributions of the computational finance community.

If you are just getting started with R and computational finance have a look at John Nolan’s R as a Tool in Computational Finance. Other resources for R and computational finance that you may find helpful are::

Package Vignettes
Several of the Finance related packages have very informative vignettes or associated websites. For example have a look at those for the packages portfolio, rugarch, rquantlib (check out the cool rotating distributions), PerformanceAnalytics, and MarkowitzR.

Data
Quandl has become a major source for financial data, which can be easily accessed from R.

Websites
Relevant websites include the RMetrics site, The R Trader,  Burns Statistics and Guy Yollin’s repository of presentations

YouTube
Three videos that.I found to be particularly interesting are recordings of the presentations “Finance with R” by  Ronald Hochreiter,  “Using R in Academic Finance” by Sanjiv Das and Portfolio Construction in R by Elliot Norma.

Blogs
Over the past couple of years, RBloggers has  posted quite a few finance related applications. Prominent among these is the series on Quantitative Finance Applications in R by Daniel Harrison on the Revolutions Blog.

Books
Books on R and Finance include the excellent RMetrics series of ebooks, Statistics and Data Analysis for Financial Engineering by David Ruppert, Financial Risk Modeling and Portfolio Optimization with R by Bernard Pfaff, Introduction to R for Quantitative Finance by Daróczi et al. and a brand new title Computational Finance: An Introductory Course with R by Agrimiro Arratia.

Coursera
This August, Eric Zivot will teach the course Introduction to Computational Finance and Financial Econometrics which will emphasize R.

The R Journal
The R Journal frequently publishes finance related papers. The present issue: Volume 5/2, December 2013 contains three relevant papers. Performance Attribution for Equity Portfolios by Yang Lu, David Kane, Temporal Disaggregation of Time Series by Christoph Sax, Peter Steiner, and betategarch: Simulation, Estimation and Forecasting of Beta-Skew-t-EGARCH Models by Genaro Sucarrat.

Conferences
in addition to R/Finance (Chicago) and useR!2014 (Los Angeles) look for R based, computational finance expertise at the 8th R/RMetrics Workshop (Paris).

Community
R-Sig-Finance is one of R’s most active special interest groups.

Quantitative Finance Applications in R - 5: an Introduction to Monte Carlo Simulation

by Daniel Hanson

Last time, we looked at the four-parameter Generalized Lambda Distribution, as a method of incorporating skew and kurtosis into an estimated distribution of market returns, and capturing the typical fat tails that the normal distribution cannot.  Having said that, however, the Normal distribution can be useful in constructing Monte Carlo simulations, and it is still commonly found in applications such as calculating the Value at Risk (VaR) of a portfolio, pricing options, and estimating the liabilities in variable annuity contracts. 

We will start here with a simple example using R, focusing on a single security.  Although perhaps seemingly trivial, this lays the foundation for in more complexities such as multiple correlated securities and stochastic interest rates.  Discussion of these topics is planned for articles to come, as well as topics in option pricing.

Single Security Example

Under the oft-used assumption of Brownian Motion dynamics, the return of a single security (eg, an equity) over a period of time Δt is approximately [See Pelsser for example.]

μΔt + σZ・sqrt(Δt)                                                                (*)

where μ is the mean annual return of the equity (also called the drift), and σ is its annualized volatility (i.e., standard deviation).  Z is a standard Normal random variable, which makes the second term in the expression stochastic.  The time t is measured in units of years, so for quarterly returns, for example, Δt = 0.25.

As μ, σ, and Δt are all known values, generating a simulated distribution of returns is a simple task.  As an example, suppose we are interested in constructing a distribution of quarterly returns, where μ = 10% and σ= 15%.  In order to get a reasonable approximation of the distribution, we will generate n = 10,000 returns. 

n <- 10000
# Fixing the seed gives us a consistent set of simulated returns
set.seed(106)
z <- rnorm(n)        # mean = 0 and sd = 1 are defaults
mu <- 0.10
sd <- 0.15
delta_t <- 0.25
# apply to expression (*) above
qtr_returns <- mu*delta_t + sd*z*sqrt(delta_t)  

Note that R is “smart enough” here by adding the scalar mu*delta_t to each element of the vector in the second term, thus giving us a set of 10,000 simulated returns. Finally, let’s check out results.  First, we plot a histogram:

hist(qtr_returns, breaks = 100, col = "green")

This gives us the following:

The symmetric bell shape of the histogram is consistent with the Normal assumption.  Checking the annualized mean and variance of the simulated returns,

stats <- c(mean(qtr_returns) * 4, sd(qtr_returns) * 2)   # sqrt(4)
names(stats) <- c("mean", "volatility")
stats

We get:

      mean    volatility
0.09901252    0.14975805

which is very close to our original parameter settings of μ = 10% and σ= 15%.

Again, this is rather simple example, but in future discussions, we will see how it extends to using Monte Carlo simulation for option pricing and risk management models.

Quantitative Finance Applications in R - 4: Using the Generalized Lambda Distribution to Simulate Market Returns

 This post is currently unavailable.

BitCoin profits with the Sushi-Burger Shuffle

The BitCoin cryptocurrency has been much in the news of late. What, you don't have BitCoins? (Don't worry, neither do I.) Unless you have a supercomputer in your back yard and a cheap source of power, it's no longer really feasible to mine them yourself. But if you want some, several online exhanges will let you buy BitCoins for real money. But be warned: the price of BitCoins has been wildly volatile over the last year or so, so it's not really clear whether buying BitCoins would be a good long term investment.

BitCoin USD exchange rates at MtGox, Aug 2013-Feb 2014

But what if you could make money with BitCoins, without having to hold any over the long term? Here's one way you could do it, right now:

1. Start with $100 US Dollars (USD)
2. Convert your USD$100 to 10609 Japanese Yen (JPY)
3. Buy 0.82963 BitCoins with your JPY10609 on the MtGox exchange
4. Sell your 0.82963 BitCoins for $113.42 USD
5. Profit!! (to the tune of $13.42)

Now, exchange rates (especially BitCoin exhange rates) vary all the time, so you'll need to do a real-time arbitrage analysis to find a profitable sequence of trades at any given moment. R programmer Tom Johnson showed at the Bay Area R User Group an R script he wrote to do exactly that, pulling real-time foreign-exchange rates from Quandl (with the quandl package for R) and solving the necessary equations to find the arbitrage opportunity. He's wrapped this R script into an easy-to-use Shiny app, so you can find BitCoin arbitrage opportunities via JPY and USD at any time:

So why isn't everyone rushing to MtGox to profit from the "Sushi-Burger Shuffle?". Well, as with most free-money schemes, real-life problems intervene. The main issue is that BitCoin currency exchanges routinely take upwards of 10 minutes to clear, by which time the exchange rates may have changed — elimitating the profit opportunity, or even leading to a loss. And that's on a good day: in recent days, it's been difficult to access BitCoin exchanges at all. So this is more of an interesting puzzle than a real money-making opportunity. Nonetheless, it's also a great example of real-time financial analysis using R.

Tom Johnson: Best 2-Currency Arbitrage with Bitcoin