add.rule: add a rule to a strategy
In cloudcell/quantstrat: Quantitative Strategy Model Framework

Description Usage Arguments Details Value

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)

`strategy`	an object of type 'strategy' or a name of a 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 '<name>.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

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.

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

cloudcell/quantstrat documentation built on May 13, 2019, 8:03 p.m.