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)debug
usablestrategy was the name of a strategy, the name. It
it was a strategy, the updated strategy.
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:
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.