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&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, the performance of 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.
Argument Matching
Many places in quantstrat apply arguments passed in the strategy specification,
the parameters list, or in ...
to an indicator, signal, or rule function.
These arguments are matched in this order, with the last math overriding.
Specifically, this order is:
arguments=list(...)
assigned to each indicator, signal, or rule
parameters=list{...}
applied when applyStrategy
is called
...
in the call to applyStrategy
quantmod
,
blotter
,
FinancialInstrument
,
blotter
,
PerformanceAnalytics