Thursday, December 15, 2011

R/Finance 2012 Call for Papers

I'm excited to share the call for papers for the upcoming R/Finance conference.  Even if you don't submit a presentation, I hope to see you there!


Call for Papers:

R/Finance 2012: Applied Finance with R
May 11 and 12, 2012
University of Illinois, Chicago, IL, USA

The fourth annual R/Finance conference for applied finance using R will be held on May 11 and 12, 2012 in Chicago, IL, USA on the campus of the University of Illinois at Chicago. The two-day conference will cover topics including portfolio management, time series analysis, advanced risk tools, high-performance computing, market microstructure, and econometrics. All will be discussed within the context of using R as a primary tool for financial risk management, portfolio construction, and trading.

Over the past three years, R/Finance has included attendees from around the world and featured keynote presentations from prominent academics and practitioners. We anticipate another exciting line-up for 2012 -- including keynote presentations from Blair Hull, Paul Gilbert, Rob McCulloch, and Simon Urbanek.

We invite you to submit complete papers or one-page abstracts (in txt or pdf format) for consideration. Academic and practitioner proposals related to R are encouraged. We welcome submissions for full talks, abbreviated "lightning talks", and for a limited number of (longer) pre-conference seminar sessions.

Presenters are strongly encouraged to provide working R code to accompany the presentation/paper. Data sets should also be made public for the purposes of reproducibility (though we realize this may be limited due to contracts with data vendors). Preference may be given to presenters who have released R packages.

Travel and accommodation grants may be available for selected presenters at the discretion of the committee. In addition, the conference will award prizes for best papers. To be eligible for a best paper award, a submission must be a full paper. Extended abstracts, even if a full paper by conference time, are not eligible for a best paper award.

Please send submissions to: committee at RinFinance.com.

The submission deadline is January 31, 2012. Submitters will be notified of acceptance via email by February 28, 2012. Notification of whether a presentation will be a long presentation or a lightning talk will also be made at that time.

Additional details will be announced at this website as they become available. Information on previous year's presenters and their presentations are also at the conference website R/Finance 2009, 2010, and 2011.

For the program committee:
    Gib Bassett, Peter Carl, Dirk Eddelbuettel, Brian Peterson,
    Dale Rosenthal, Jeffrey Ryan, Joshua Ulrich

Tuesday, September 27, 2011

Denver 10/1-10/5

I will be traveling to Denver from 10/1-10/5.  Drop me a line if you're in the area and would like to meet for coffee / drinks.

Thursday, September 1, 2011

TTR_0.21-0 on CRAN

An updated version of TTR is now on CRAN.  It contains some much-needed bug fixes (most notably to stockSymbols), some small changes, and a few new functions.  Note that the change to wilderSum will affect functions that use it (e.g. ADX).

Here are the full contents of the CHANGES file:

TTR version 0.21-0
  Changes from version 0.20-2

NEW FEATURES:
CHANGES:
  • Added wilder and ratio arguments to DEMA. Thanks to Matthew Fornari for the suggestion.
  • Changed wilderSum to seed initial value with raw sum. This matches Wilder's original calculations. Thanks to Mahesh Bp for the report.
  • The BBands sd calculation now uses the population instead of sample statistic. This is consistent with Bollinger Band literature. Thanks to Jeff Ryan for the patch.
BUG FIXES:
  • Fixed stockSymbols for nasdaq.com changes.
  • Fixed ZLEMA default ratio by changing it from 2/(n-1) to 2/(n+1). This makes it consistent with EMA. Thanks to Dirk Eddelbuettel.
  • Corrected close-to-close volatility. Thanks to James Toll for the report.
  • adjRatios failed (spectacularly) if there were missing close prices. Thanks to Garrett See for the report.

Tuesday, August 23, 2011

Tactical asset allocation using quantstrat

As promised in the introduction to quantstrat, here is an example strategy.  I thought I'd start with the obligatory tactial asset allocation (TAA) strategy.  This post will replicate the strategy in the post, tactical asset allocation using blotter.

The "faber" demo in the quanstrat package contains a TAA strategy but it uses a slightly different approach than the code we're trying to replicate.  There are two major differences:
  1. The blotter TAA code initiates a position at the first observation where the close is above the SMA.  The demo only initiates a position when the close crosses the SMA to the upside.

    For example, assume the close is above the SMA at the beginning of the sample.  The demo has to wait for the close to drop below the SMA and then cross above it before taking a position; the blotter TAA code initiates a position on the first observation.

  2. The blotter TAA code calculates order size based on total account equity (as stored in the UnitSize object).  The demo always uses an order size of 1,000 shares, regardless of total account value (in case you're wondering, yes, capital/equity-aware order sizing is on the to-do list).
We need to make a few changes to the demo(faber) code to make it work more like the blotter TAA post.  First, we change the add.signal calls to use sigCrossover instead of sigComparison.  This allows us to create an order on the first observation, rather than wait for a crossover.

Next, we need to change the first call to add.rule (the entry rule).  sigComparison will be TRUE for every period where the close is above the SMA and we don't want to buy 1000 shares every period, so we need to tell ruleSignal to use the max position order sizing function.  We do this by adding osFUN=osMaxPos to the list of arguments passed to ruleSignal.

Finally, we need to set the position limits for each instrument.  We do this via two calls to addPosLimit (one for each symbol) and we set the maximum position to 1000 shares and the minimum position to 0 shares.

The modified code is below and even includes some simple evaluation of the results at no extra charge.  The tradeStats function has a ton more columns; I've only selected a few to make the output more readable.  Feel free to tinker.

NOTE: I wrote this code using the latest quantmod, xts, and zoo from CRAN; and the latest blotter, FinancialInstrument, and quantstrat from R-Forge.

# This code is a slight modification of the quantstrat "faber" demo, intended to replicate 
# http://blog.fosstrading.com/2009/11/tactical-asset-allocation-using-blotter.html 
# Uncomment the line below to install the latest packages on R-Forge:
#install.packages(c("quantstrat","blotter","FinancialInstrument"), repos="http://r-forge.r-project.org")
require(quantstrat)
require(PerformanceAnalytics)

# Set initial values
initDate <- "2002-07-31"
endDate <- "2009-10-31"
initEq <- 100000

# Pull Yahoo Finance data
symbols <- c("IEF", "SPY")
getSymbols(symbols, from=initDate, to=endDate, index.class=c("POSIXt","POSIXct"))

# adjust for splits/dividends (comment to replicate blotter example)
#IEF <- adjustOHLC(IEF, use.Adjusted=TRUE)
#SPY <- adjustOHLC(SPY, use.Adjusted=TRUE)

# convert to monthly
IEF <- to.monthly(IEF, indexAt="endof")
SPY <- to.monthly(SPY, indexAt="endof")

# Set up instruments with FinancialInstruments package
currency("USD")
for(symbol in symbols) {
  stock(symbol, currency="USD", multiplier=1)
}

# Delete portfolio, account, and order book if they already exist
suppressWarnings(rm("account.faber","portfolio.faber",pos=.blotter))
suppressWarnings(rm("order_book.faber",pos=.strategy))

# Initialize portfolio and account
initPortf("faber", symbols=symbols, initDate=initDate)
initAcct("faber", portfolios="faber", initDate=initDate, initEq=initEq)
initOrders(portfolio="faber", initDate=initDate)

# Initialize a strategy object
stratFaber <- strategy("faber")

# Add the 10-month SMA indicator
stratFaber <- add.indicator(strategy=stratFaber, name="SMA",
  arguments=list(x=quote(Cl(mktdata)), n=10), label="SMA10")

# There are two signals:
# The first is when monthly price crosses over the 10-month SMA
stratFaber <- add.signal(stratFaber, name="sigComparison",
  arguments=list(columns=c("Close","SMA10"),relationship="gte"), label="Cl.gt.SMA")
# The second is when the monthly price crosses under the 10-month SMA
stratFaber <- add.signal(stratFaber, name="sigComparison",
  arguments=list(columns=c("Close","SMA10"),relationship="lt"), label="Cl.lt.SMA")

# There are two rules:
# The first is to buy when the price crosses above the SMA
stratFaber <- add.rule(stratFaber, name="ruleSignal",
  arguments=list(sigcol="Cl.gt.SMA", sigval=TRUE, orderqty=1000, ordertype="market",
  orderside="long", pricemethod="market", TxnFees=-5, osFUN=osMaxPos), type="enter", path.dep=TRUE)
# The second is to sell when the price crosses below the SMA
stratFaber <- add.rule(stratFaber, name="ruleSignal",
  arguments=list(sigcol="Cl.lt.SMA", sigval=TRUE, orderqty="all", ordertype="market",
  orderside="long", pricemethod="market", TxnFees=-5), type="exit", path.dep=TRUE)

# Set position limits so we don't add to the position every month Close > SMA10
addPosLimit("faber", "SPY", timestamp=initDate, maxpos=1000, minpos=0)
addPosLimit("faber", "IEF", timestamp=initDate, maxpos=1000, minpos=0)

# Process the indicators and generate trades
out <- try(applyStrategy(strategy=stratFaber, portfolios="faber"))
updatePortf("faber")

# Evaluate results
portRet <- PortfReturns("faber")
portRet$Total <- rowSums(portRet, na.rm=TRUE)
charts.PerformanceSummary(portRet$Total)
tradeStats("faber")[,c("Symbol","Num.Trades","Net.Trading.PL","maxDrawdown")]


Friday, August 12, 2011

Introduction to quantstrat

quantstrat provides a generic infrastructure to model and backtest signal-based quantitative strategies.  It is a high-level abstraction layer (built on xts, FinancialInstrument, blotter, etc.) that allows you to build and test strategies in very few lines of code.  quantstrat is still under heavy development but is being used every day on real portfolios.  We encourage you to send contributions and test cases to the project forums.

This post is a joint effort between me and Brian Peterson.  It will describe the underlying philosophy of quantstrat and how quantstrat implements that philosophy.  You may have seen some of this in Brian's Quantitative Strategy Development in R lightning talk at R/Finance 2011.

Generic Signal-Based Strategy Modeling

A signal-based strategy model first generates indicators.  Indicators are quantitative values derived from market data (e.g. moving averages, RSI, volatility bands, channels, momentum, etc.).  Indicators should be applied to market data in a vectorized (for fast backtesting) or streaming (for live execution) fashion, and are assumed to be path-independent (i.e. they do not depend on account / portfolio characteristics, current positions, or trades).

The interaction between indicators and market data are used to generate signals (e.g. crossovers, thresholds, multiples, etc.).  These signals are points in time at which you may want to take some action, even though you may not be able to.  Like indicators, signals may be applied in a vectorized or streaming fashion, and are assumed to be path-independent.

Rules use market data, indicators, signals, and current account / portfolio characteristics to generate orders.  Notice that rules about position sizing, fill simulation, order generation / management, etc. are separate from the indicator and signal generation process.  Unlike indicators and signals, rules are generally evaluated in a path-dependent fashion (path-independent rules are supported but are rare in real life) and are aware of all prior market data and current positions at the time of evaluation.  Rules may either generate new or modify existing orders (e.g. risk management, fill, rebalance, entry, exit).

How quantstrat Models Strategies

quantstrat uses FinancialInstrument to specify instruments (including their currencies) and uses blotter to keep track of transactions, valuations, and P&amp;amp;L across portfolios and accounts.

Indicators are often standard technical analysis functions like those found in TTR; and signals are often specified by the quantstrat sig* functions (i.e. sigComparison, sigCrossover, sigFormula, sigPeak, sigThreshold).  Rules are typically specified with the quantstrat ruleSignal function.

The functions used to specify indicators, signals, and rules are not limited to those mentioned previously.  The name parameter to add.indicator, add.signal, and add.rule can be any R function.  Because the supporting toolchain is built using xts objects, custom functions will integrate most easily if they return xts objects.

The strategy model is created in layers and makes use of delayed execution.  This means strategies can be applied--unmodified--to several different portfolios.  Before execution, quantstrat strategy objects do not know what instruments they will be applied to or what parameters will be passed to them.

For example, indicator parameters such as moving average periods or thresholds are likely to affect strategy performance.  Default values for parameters may (optionally) be set in the strategy object, or set at call-time via the parameters argument of applyStrategy (parameters is a named list, used like the arguments lists).

quantstrat models orders, which may or may not become transactions.  This provides a lot of extra ability to evaluate how the strategy is actually working, not working, or could be improved.  For example, performance strategies are often affected by how often resting limit orders are changed / replaced / canceled.  An order book allows the quantitative strategist to examine market conditions at the time these decisions are made. Also, the order history allows for easy computation of things that are important for many strategies, like order-to-fill ratios.

What's next?
  • Examples!  You can run some demos while you wait:
      demo(package="quantstrat")
  • Strategy Evaluation
  • Parameter Evaluation

Wednesday, July 27, 2011

Creating Financial Instrument metadata in R

(This is a guest post by Ilya Kipnis)

When trading stocks in a single currency, instrument metadata can be safely ignored because the multiplier is 1 and the currencies are all the same.  When doing analysis on fixed income products, options, futures, or other complex derivative instruments, the data defining the properties of these instruments becomes critical to tasks like accounting for value of trades, or comparing notional value between more than one instrument. The FinancialInstrument package provides a construct for storing metadata for tradeable contracts (referred to as instruments, e.g. stocks, futures, options, etc.) and their root representations.  It can be used to create any asset class and complex derivatives, across multiple currencies. 

In tactical asset allocation using blotter, Joshua Ulrich used FinancialInstrument (blotter depends on it) to create a stock portfolio.  FinancialInstrument is also a required dependency of the quantstrat quantitative strategy framework in R (quantstrat will be covered in a later post).

Creating a list of historical symbols is a recurring challenge with historical data on derivative instruments.  These symbols tend to follow a deterministic pattern and FinancialInstrument provides utility functions to create the symbols traded over specific periods of time. These symbols could then be used to request historical data from a data vendor or to construct instrument objects in R.

The simplest function for generating a series of symbols is build_series_symbols.  Let's look at it with a small example using crude oil (CL) and STOXX (STXE) futures:

    # install.packages("FinancialInstrument", repos="http://R-Forge.R-project.org")
    require(FinancialInstrument)
    Data <- data.frame(primary_id="CL", month_cycle="F,G,H,J,K,M,N,Q,U,V,X,Z")
    Data <- rbind(Data, data.frame(primary_id="STXE", month_cycle="H,M,U,Z"))
    Data
    #   primary_id               month_cycle
    # 1         CL   F,G,H,J,K,M,N,Q,U,V,X,Z
    # 2       STXE                   H,M,U,Z


The Data object contains two columns.  The primary_id is the root contract that identifies the instrument, and the month_cycle defines the months the contracts trade in (e.g. “H,M,U,Z” for Mar/Jun/Sep/Dec).

build_series_symbols only needs Data and yearlist.   yearlist is the suffix for expiration years and 0, 1, 2 represent 2010, 2011, 2012 in this example.  build_series_symbols returns a vector of series symbols that we could use to request data or create future_series instruments.

    build_series_symbols(Data, yearlist=c(0,1,2))
     [1] "CLF0"   "CLG0"   "CLH0"   "CLJ0"   "CLK0"   "CLM0"   "CLN0"   "CLQ0" 
     [9] "CLU0"   "CLV0"   "CLX0"   "CLZ0"   "STXEH0" "STXEM0" "STXEU0" "STXEZ0"
    [17] "CLF1"   "CLG1"   "CLH1"   "CLJ1"   "CLK1"   "CLM1"   "CLN1"   "CLQ1" 
    [25] "CLU1"   "CLV1"   "CLX1"   "CLZ1"   "STXEH1" "STXEM1" "STXEU1" "STXEZ1"
    [33] "CLF2"   "CLG2"   "CLH2"   "CLJ2"   "CLK2"   "CLM2"   "CLN2"   "CLQ2" 
    [41] "CLU2"   "CLV2"   "CLX2"   "CLZ2"   "STXEH2" "STXEM2" "STXEU2" "STXEZ2"

A more complicated task is to create symbols for exchange guaranteed calendar spreads.  The build_spread_symbols function creates a vector of symbols for spreads of securities (currently coded for futures calendar spreads but can be extended and generalized) in a very shorthand notation.

build_spread_symbols accepts instrument specifications via either a file path or (preferably) a data frame (using the file or data arguments, respectively). Output can be assigned to an object or written to a file using the optional outputfile argument.  The default starting date is the current date, but the user can manually set a starting date (e.g. historical dates for backtesting, and future dates to create lists of instruments to be traded in the future).

    # read in data that would be suitable for load.instruments on root contracts
    Data <- read.csv("series_data.csv", stringsAsFactors=FALSE)
    # set the type to guaranteed_spread
    Data$type <- "guaranteed_spread"
    # call build_spread_symbols
    output <- build_spread_symbols(Data[6:7,], start_date="2010-01-01")


The critical fields in the data (CSV or data frame) are the primary_id, the type (e.g. future, calendar spread, intercommodity spread, etc.), the month_cycle, and the active_months (how many contracts to display).  For instance, an active_months value of 12 on a contract that trades quarterly (“H,M,U,Z”) would create front month contracts for the next 3 years.  An active_months value of 6 on this same quarterly contract would produce 1.5 years.  On a contract that trades 12 months a year (“F,G,H,J,K,M,N,Q,U,V,X,Z”), an active_months value of 12 would produce 1 year of contracts, and a value of 6 would only produce half a year.

Lastly, the contracts_ahead field specifies the month spread on calendar spread type securities.  Note that these are contracts ahead and not months ahead.  For example, if you consider a contract trading “H,M,U,Z” vs. a contract trading “F,G,H,J,K,M,N,Q,U,V,X,Z”, a value of 1 for the “H,M,U,Z” contract would create an H1-M1 spread or the like, while a value of 1 with the 12-month traded contract would create an F1-G1 spread.

The rest of the columns simply get carried over, for further use in other programs/scripts/procedures, such as the load.instruments function.

About the Author: Ilya Kipnis holds a Master's degree in Statistics from Rutgers, and uses and contributes to the R packages blotter, FinancialInstrument, and quantstrat. Ilya may be contacted for consulting and full-time opportunities in finance at ilya.kipnis@gmail.com.

Thursday, June 23, 2011

The R Journal, Volume 3/1

The most recent issue of The R Journal was recently published.  If you're not a regular reader, you should at least check out the following three contributed articles (listed in order of appearance).