add.rule

0th

Percentile

add a rule to a strategy

Rules will be processed in a very particular manner, so it bears going over.

Usage
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)
Arguments
strategy
an object of type 'strategy' to add the rule to
name
name of the rule, must correspond to an R function
arguments
named list of default arguments to be passed to an rule function when executed
parameters
vector of strings naming parameters to be saved for apply-time definition
label
arbitrary text label for rule output, NULL default will be converted to '.rule'
type
one of "risk","order","rebalance","exit","enter","chain" see Details
parent
the label of the parent rule for a chain rule
...
any other passthru parameters
enabled
TRUE/FALSE whether the rule is enabled for use in applying the strategy, default TRUE
indexnum
if you are updating a specific rule, the index number in the $rules[type] list to update
path.dep
TRUE/FALSE whether rule is path dependent, default TRUE, see Details
timespan
an xts/ISO-8601 style time subset, like "T08:00/T15:00", see Details
store
TRUE/FALSE whether to store the strategy in the .strategy environment, or return it. default FALSE
storefun
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
Details

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:

risk
rules that check and react to risk of positions, may stop all other rule execution temporarily or permanently
order
rules for order processing of any open orders at time t, always path-dependent

rebalance
rules executed specifically in a portfolio context, unnecessary in univariate strategies

exit
rules to determine whether to exit a position

enter
rules to determine whether to enter or increase a position
chain
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.

Value

if strategy was the name of a strategy, the name. It it was a strategy, the updated strategy.

Aliases
  • add.rule
Documentation reproduced from package quantstrat, version 0.8.2, License: GPL-3

Community examples

Looks like there are no examples yet.