Rules will be processed in a very particular manner, so it bears going over.
add.rule(strategy, name, arguments, parameters = NULL, label = NULL,
type = c(NULL, "risk", "order", "rebalance", "exit", "enter", "chain"),
parent = NULL, ..., enabled = TRUE, indexnum = NULL,
path.dep = TRUE, timespan = NULL, store = FALSE, storefun = TRUE)an object of type 'strategy' to add the rule to
name of the rule, must correspond to an R function
named list of default arguments to be passed to an rule function when executed
vector of strings naming parameters to be saved for apply-time definition
arbitrary text label for rule output, NULL default will be converted to '<name>.rule'
one of "risk","order","rebalance","exit","enter","chain" see Details
the label of the parent rule for a chain rule
any other passthru parameters
TRUE/FALSE whether the rule is enabled for use in applying the strategy, default TRUE
if you are updating a specific rule, the index number in the $rules[type] list to update
TRUE/FALSE whether rule is path dependent, default TRUE, see Details
an xts/ISO-8601 style time subset, like "T08:00/T15:00", see Details
TRUE/FALSE whether to store the strategy in the .strategy environment, or return it. default FALSE
TRUE/FALSE whether to store the function in the rule, default TRUE. setting this option to FALSE may slow the backtest, but makes debug usable
if strategy was the name of a strategy, the name. It it was a strategy, the updated strategy.
First, rules are either path dependent or non-path-dependent. Path dependent rules
will be processed in every time increment for the mktdata passed into
applyStrategy. Non path dependent rules will likely be quite rare in real life,
and will be applied after indicators and signals, and before path-dependent rules are processed.
All rules have a type. These may be any of:
rules that check and react to risk of positions, may stop all other rule execution temporarily or permanently
rules for order processing of any open orders at time t, always path-dependent
rules executed specifically in a portfolio context, unnecessary in univariate strategies
rules to determine whether to exit a position
rules to determine whether to enter or increase a position
rules executed upon fill of an order corresponding to the label of the parent rule identified by the parent arg.
The rules will be executed by type, in the order listed above. Multiple rules of each type may be defined, as with signals and indicators, they will be executed in order by index number with any other rules sharing the same type.
The rule execution order was constructed because path-dependent rules may modify the ability of rules that have not fired yet to be evaluated. For example, a risk rule may flatten (close out) an entire position and put new orders on hold, effectively stopping all further execution of the strategy. Another example would be a rebalancing rule function that would enter orders to rebalance the portfolio, and would hold other strategy processing until the rebalancing period was over.
The timespan parameter will limit rule execution by time of day using
time based subsetting. See ISO-8601 specification and xts documentation for
more details. Note that these are only applicable to intra-day execution,
and will remain that way barring patches (tests and documentation) from
interested parties. The subsetting may (will likely) work with normal
ISO/xts subset ranges, but consider it unsupported.
The name parameter should be a character string naming the function
to be called in the applyRules loop. The add.rule
function will then call match.fun, ands store the actual function
in your strategy object.
This will avoid lookups via match.fun at applyRules time,
and may provide a significant speed increase on higher frequency data (20% or more).
We anticipate that rules will be the portion of a strategy most likely to not have suitable template code included with this package, as every strategy and environment are different, especially in this respect. We will attempt to provide enough examples and generic rules to give strategy authors a place to start.
For quantstrat to be able to (largly) vectorize the execution of path-dependent
rule evaluation, the rule function is presumed to have a function signature
like that of ruleSignal, specifically the arguments sigcol
and sigval. If these are present and function in a manner similar to
ruleSignal we can do some preprocessing to significantly reduce the
dimensionality of the index we need to loop over. The speedup is the ratio of
(symbols\*total observations)/signal observations, so it can be significant for many strategies.