add.rule: add a rule to a strategy

Description Usage Arguments Details Value

Description

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

Usage

1
2
3
4
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 '<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

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.


redmode/quantstrat documentation built on May 27, 2019, 4:04 a.m.