[Blotter-commits] r724 - in pkg/quantstrat: . man
noreply at r-forge.r-project.org
noreply at r-forge.r-project.org
Wed Aug 10 18:26:41 CEST 2011
Author: braverock
Date: 2011-08-10 18:26:41 +0200 (Wed, 10 Aug 2011)
New Revision: 724
Modified:
pkg/quantstrat/DESCRIPTION
pkg/quantstrat/NAMESPACE
pkg/quantstrat/man/add.indicator.Rd
pkg/quantstrat/man/add.paramLookupTable.Rd
pkg/quantstrat/man/add.parameter.Rd
pkg/quantstrat/man/add.rule.Rd
pkg/quantstrat/man/add.signal.Rd
pkg/quantstrat/man/addOrder.Rd
pkg/quantstrat/man/addPosLimit.Rd
pkg/quantstrat/man/applyIndicators.Rd
pkg/quantstrat/man/applyRules.Rd
pkg/quantstrat/man/applySignals.Rd
pkg/quantstrat/man/applyStrategy.Rd
pkg/quantstrat/man/getOrderBook.Rd
pkg/quantstrat/man/getOrders.Rd
pkg/quantstrat/man/getParams.Rd
pkg/quantstrat/man/getPosLimit.Rd
pkg/quantstrat/man/getStrategy.Rd
pkg/quantstrat/man/initOrders.Rd
pkg/quantstrat/man/is.strategy.Rd
pkg/quantstrat/man/match.names.Rd
pkg/quantstrat/man/osMaxPos.Rd
pkg/quantstrat/man/osNoOp.Rd
pkg/quantstrat/man/paramLookup.Rd
pkg/quantstrat/man/ruleOrderProc.Rd
pkg/quantstrat/man/ruleSignal.Rd
pkg/quantstrat/man/sigComparison.Rd
pkg/quantstrat/man/sigCrossover.Rd
pkg/quantstrat/man/sigFormula.Rd
pkg/quantstrat/man/sigPeak.Rd
pkg/quantstrat/man/sigThreshold.Rd
pkg/quantstrat/man/strategy.Rd
pkg/quantstrat/man/updateOrders.Rd
Log:
- update roxygen docs
- raise dependency for xts to latest stable
- bump version
Modified: pkg/quantstrat/DESCRIPTION
===================================================================
--- pkg/quantstrat/DESCRIPTION 2011-08-09 21:09:10 UTC (rev 723)
+++ pkg/quantstrat/DESCRIPTION 2011-08-10 16:26:41 UTC (rev 724)
@@ -1,17 +1,28 @@
Package: quantstrat
Type: Package
Title: Quantitative Strategy Model Framework
-Version: 0.5.0
+Version: 0.5.1
Date: $Date$
-Author: Peter Carl, Dirk Eddelbuettel, Brian G. Peterson,
- Jeffrey A. Ryan, Joshua Ulrich, Garrett See, Yu Chen
-Depends: xts(>= 0.7-6.15),TTR(>= 0.2),blotter(>= 0.7.2),
- FinancialInstrument, quantmod (>= 0.3-14)
-Suggests: PerformanceAnalytics,PortfolioAnalytics
+Author: Peter Carl, Dirk Eddelbuettel, Brian G. Peterson,
+ Jeffrey A. Ryan, Joshua Ulrich, Garrett See, Yu Chen
+Depends:
+ xts(>= 0.8-2),TTR(>= 0.2),blotter(>= 0.7.2),
+ FinancialInstrument,
+ quantmod (>= 0.3-17)
+Suggests:
+ PerformanceAnalytics,PortfolioAnalytics
Maintainer: Jeffrey A. Ryan <jeff.a.ryan at gmail.com>
-Description: Specify, build, and back-test quantitative financial
- trading and portfolio strategies
+Description: Specify, build, and back-test quantitative
+ financial trading and portfolio strategies
LazyLoad: yes
License: GPL-3
-Collate: 'indicators.R' 'match.names.R' 'orders.R' 'parameters.R'
- 'rules.R' 'signals.R' 'strategy.R' 'traderules.R'
+Collate:
+ 'indicators.R'
+ 'initialize.R'
+ 'match.names.R'
+ 'orders.R'
+ 'parameters.R'
+ 'rules.R'
+ 'signals.R'
+ 'strategy.R'
+ 'traderules.R'
Modified: pkg/quantstrat/NAMESPACE
===================================================================
--- pkg/quantstrat/NAMESPACE 2011-08-09 21:09:10 UTC (rev 723)
+++ pkg/quantstrat/NAMESPACE 2011-08-10 16:26:41 UTC (rev 724)
@@ -1,34 +1,33 @@
export(add.indicator)
-export(applyIndicators)
-export(match.names)
-export(getOrderBook)
-export(initOrders)
-export(getOrders)
export(addOrder)
-export(updateOrders)
-export(ruleOrderProc)
export(add.parameter)
export(add.paramLookupTable)
-export(getParameterTable)
-export(setParameterDistribution)
-export(applyParameter)
-export(paramConstraint)
-export(setParameterConstraint)
+export(addPosLimit)
export(add.rule)
-export(applyRules)
export(add.signal)
+export(applyIndicators)
+export(applyParameter)
+export(applyRules)
export(applySignals)
+export(applyStrategy)
+export(getOrderBook)
+export(getOrders)
+export(getParameterTable)
+export(getPosLimit)
+export(getStrategy)
+export(initOrders)
+export(is.strategy)
+export(match.names)
+export(osMaxPos)
+export(osNoOp)
+export(ruleOrderProc)
+export(ruleSignal)
+export(setParameterConstraint)
+export(setParameterDistribution)
export(sigComparison)
export(sigCrossover)
+export(sigFormula)
export(sigPeak)
export(sigThreshold)
-export(sigFormula)
export(strategy)
-export(applyStrategy)
-export(is.strategy)
-export(getStrategy)
-export(ruleSignal)
-export(osNoOp)
-export(addPosLimit)
-export(getPosLimit)
-export(osMaxPos)
+export(updateOrders)
Modified: pkg/quantstrat/man/add.indicator.Rd
===================================================================
--- pkg/quantstrat/man/add.indicator.Rd 2011-08-09 21:09:10 UTC (rev 723)
+++ pkg/quantstrat/man/add.indicator.Rd 2011-08-10 16:26:41 UTC (rev 724)
@@ -1,45 +1,94 @@
\name{add.indicator}
\alias{add.indicator}
-\title{add an indicator to a strategy...}
-\usage{add.indicator(strategy, name, arguments, parameters, label, ...,
- enabled=TRUE, indexnum, store=FALSE)}
-\description{add an indicator to a strategy}
-\details{Indicators are typically standard technical or statistical analysis outputs,
-such as moving averages, bands, or pricing models.
+\title{add an indicator to a strategy}
+\usage{
+ add.indicator(strategy, name, arguments, parameters =
+ NULL, label = NULL, ..., enabled = TRUE, indexnum = NULL,
+ store = FALSE)
+}
+\arguments{
+ \item{strategy}{an object of type 'strategy' to add the
+ indicator to}
-Indicators are always path-independent, and should be constructed from vectorized functions where possible.
+ \item{name}{name of the indicator, must correspond to an
+ R function}
-Indicators are applied before signals and rules, and the output of indicators
-may be used as inputs to construct signals or fire rules.
+ \item{arguments}{default arguments to be passed to an
+ indicator function when executed}
-\code{arguments} and \code{parameters} are named lists that describe the arguments to be passed to the indicator function.
-\code{arguments} is for defining any non-default arguments to be passed to the function named in the \code{name} of the indicator.
-For example, the \code{x} argument to a moving average function may be defined as \code{x=quote(Cl(mktdata))}
+ \item{parameters}{vector of strings naming parameters to
+ be saved for apply-time definition,default NULL, only
+ needed if you need special names to avoid argument
+ collision}
-If you look at the demo scripts, you'll notice that we often use \code{quote(mktdata)} in setting up indicators, signals, or rules.
-This tells \R to delay evaluation via \code{quote()}, and to use the special variable \code{mktdata}.
+ \item{label}{arbitrary text label for indicator output,
+ NULL default will be converted to '<name>.ind'}
-\code{mktdata} is typically created internally to \code{quantstrat} by looking in the global environment for
-a time series of prices or returns. mktdata may also contain other data you've manipulated outside quatstrat,
-though where possible you should use quantstrat to contain all the logic for the strategy, to aid in maintenance and modifications.
+ \item{...}{any other passthru parameters}
-The use of \code{quote()} tells R to not evaluate what's inside the quote until the function is evaluated later.
-By the time that code is evaluated, \code{mktdata} will be populated with the correct price information based on the contents of whatever portfolio you are evaluating the strategy on.
+ \item{enabled}{TRUE/FALSE whether the indicator is
+ enabled for use in applying the strategy, default TRUE}
-\code{parameters} is another named list, and normally will not be needed.
-If you have multiple indicator, signal, or rule functions share the that
-\emph{both} share the same argument names \emph{and} will need to have
-different values passed to those arguments as defined parameters at apply-time,
-then you may need to give them unique names so that delayed evaluation can
-sort it all out for you at apply-time.
-We will endeavor to get an example of named parameters into the demo scripts.}
-\seealso{\code{\link{quote}}}
-\arguments{\item{strategy}{an object of type 'strategy' to add the indicator to}
-\item{name}{name of the indicator, must correspond to an R function}
-\item{arguments}{default arguments to be passed to an indicator function when executed}
-\item{parameters}{vector of strings naming parameters to be saved for apply-time definition,default NULL, only needed if you need special names to avoid argument collision}
-\item{label}{arbitrary text label for indicator output, NULL default will be converted to '<name>.ind'}
-\item{...}{any other passthru parameters}
-\item{enabled}{TRUE/FALSE whether the indicator is enabled for use in applying the strategy, default TRUE}
-\item{indexnum}{if you are updating a specific indicator, the index number in the $indicators list to update}
-\item{store}{TRUE/FALSE whether to store the strategy in the .strategy environment, or return it. default FALSE}}
+ \item{indexnum}{if you are updating a specific indicator,
+ the index number in the $indicators list to update}
+
+ \item{store}{TRUE/FALSE whether to store the strategy in
+ the .strategy environment, or return it. default FALSE}
+}
+\description{
+ Indicators are typically standard technical or
+ statistical analysis outputs, such as moving averages,
+ bands, or pricing models.
+}
+\details{
+ Indicators are always path-independent, and should be
+ constructed from vectorized functions where possible.
+
+ Indicators are applied before signals and rules, and the
+ output of indicators may be used as inputs to construct
+ signals or fire rules.
+
+ \code{arguments} and \code{parameters} are named lists
+ that describe the arguments to be passed to the indicator
+ function. \code{arguments} is for defining any
+ non-default arguments to be passed to the function named
+ in the \code{name} of the indicator. For example, the
+ \code{x} argument to a moving average function may be
+ defined as \code{x=quote(Cl(mktdata))}
+
+ If you look at the demo scripts, you'll notice that we
+ often use \code{quote(mktdata)} in setting up indicators,
+ signals, or rules. This tells \R to delay evaluation via
+ \code{quote()}, and to use the special variable
+ \code{mktdata}.
+
+ \code{mktdata} is typically created internally to
+ \code{quantstrat} by looking in the global environment
+ for a time series of prices or returns. mktdata may also
+ contain other data you've manipulated outside quatstrat,
+ though where possible you should use quantstrat to
+ contain all the logic for the strategy, to aid in
+ maintenance and modifications.
+
+ The use of \code{quote()} tells R to not evaluate what's
+ inside the quote until the function is evaluated later.
+ By the time that code is evaluated, \code{mktdata} will
+ be populated with the correct price information based on
+ the contents of whatever portfolio you are evaluating the
+ strategy on.
+
+ \code{parameters} is another named list, and normally
+ will not be needed. If you have multiple indicator,
+ signal, or rule functions share the that \emph{both}
+ share the same argument names \emph{and} will need to
+ have different values passed to those arguments as
+ defined parameters at apply-time, then you may need to
+ give them unique names so that delayed evaluation can
+ sort it all out for you at apply-time. We will endeavor
+ to get an example of named parameters into the demo
+ scripts.
+}
+\seealso{
+ \code{\link{quote}}
+}
+
Modified: pkg/quantstrat/man/add.paramLookupTable.Rd
===================================================================
--- pkg/quantstrat/man/add.paramLookupTable.Rd 2011-08-09 21:09:10 UTC (rev 723)
+++ pkg/quantstrat/man/add.paramLookupTable.Rd 2011-08-10 16:26:41 UTC (rev 724)
@@ -1,9 +1,20 @@
\name{add.paramLookupTable}
\alias{add.paramLookupTable}
-\title{add parameters to strategy objects: ALPHA CODE USE WITH CARE...}
-\usage{add.paramLookupTable(strategy, type, name, paramTable)}
-\description{add parameters to strategy objects: ALPHA CODE USE WITH CARE}
-\arguments{\item{strategy}{}
-\item{type}{}
-\item{name}{}
-\item{paramTable}{}}
+\title{add parameters to strategy objects: ALPHA CODE USE WITH CARE}
+\usage{
+ add.paramLookupTable(strategy, type, name, paramTable)
+}
+\arguments{
+ \item{strategy}{}
+
+ \item{type}{}
+
+ \item{name}{}
+
+ \item{paramTable}{}
+}
+\description{
+ add parameters to strategy objects: ALPHA CODE USE WITH
+ CARE
+}
+
Modified: pkg/quantstrat/man/add.parameter.Rd
===================================================================
--- pkg/quantstrat/man/add.parameter.Rd 2011-08-09 21:09:10 UTC (rev 723)
+++ pkg/quantstrat/man/add.parameter.Rd 2011-08-10 16:26:41 UTC (rev 724)
@@ -1,15 +1,31 @@
\name{add.parameter}
\alias{add.parameter}
-\title{add parameters to strategy objects: ALPHA CODE USE WITH CARE...}
-\usage{add.parameter(strategy, type=c("indicator", "signal"), add.to.name,
- method=c("lookup", "lookup.range", "calc"), arguments, label, ...,
- store=FALSE)}
-\description{add parameters to strategy objects: ALPHA CODE USE WITH CARE}
-\arguments{\item{strategy}{}
-\item{type}{}
-\item{add.to.name}{}
-\item{method}{}
-\item{arguments}{}
-\item{label}{}
-\item{...}{}
-\item{store}{}}
+\title{add parameters to strategy objects: ALPHA CODE USE WITH CARE}
+\usage{
+ add.parameter(strategy, type = c("indicator", "signal"),
+ add.to.name, method = c("lookup", "lookup.range",
+ "calc"), arguments = NULL, label = NULL, ..., store =
+ FALSE)
+}
+\arguments{
+ \item{strategy}{}
+
+ \item{type}{}
+
+ \item{add.to.name}{}
+
+ \item{method}{}
+
+ \item{arguments}{}
+
+ \item{label}{}
+
+ \item{...}{}
+
+ \item{store}{}
+}
+\description{
+ add parameters to strategy objects: ALPHA CODE USE WITH
+ CARE
+}
+
Modified: pkg/quantstrat/man/add.rule.Rd
===================================================================
--- pkg/quantstrat/man/add.rule.Rd 2011-08-09 21:09:10 UTC (rev 723)
+++ pkg/quantstrat/man/add.rule.Rd 2011-08-10 16:26:41 UTC (rev 724)
@@ -1,74 +1,124 @@
\name{add.rule}
\alias{add.rule}
-\title{add a rule to a strategy...}
-\usage{add.rule(strategy, name, arguments, parameters, label, type=c(NULL,
- "risk", "order", "rebalance", "exit", "enter"), ..., enabled=TRUE,
- indexnum, path.dep=TRUE, timespan, store=FALSE)}
-\description{add a rule to a strategy}
-\details{Rules will be processed in a very particular manner, so it bears going over.
+\title{add a rule to a strategy}
+\usage{
+ add.rule(strategy, name, arguments, parameters = NULL,
+ label = NULL, type = c(NULL, "risk", "order",
+ "rebalance", "exit", "enter"), ..., enabled = TRUE,
+ indexnum = NULL, path.dep = TRUE, timespan = NULL, store
+ = FALSE)
+}
+\arguments{
+ \item{strategy}{an object of type 'strategy' to add the
+ rule to}
-First, rules are either path dependent or non-path-dependent. Path dependent rules
-will be processed in every time increment for the \code{mktdata} passed into
-\code{\link{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.
+ \item{name}{name of the rule, must correspond to an R
+ function}
-All rules have a \code{type}. These may be any of:
-\describe{
-\item{risk}{ rules that check and react to risk of positions, may stop all other rule execution temporarily or permanently}
-\item{order}{ rules for order processing of any open orders at time t, always path-dependent}
-\item{rebalance}{ rules executed specifically in a portfolio context, unnecessary in univariate strategies}
-\item{exit}{ rules to determine whether to exit a position}
-\item{enter}{ rules to determine whether to enter or increase a position}
-}
-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.
+ \item{arguments}{named list of default arguments to be
+ passed to an rule function when executed}
-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.
+ \item{parameters}{vector of strings naming parameters to
+ be saved for apply-time definition}
-The \code{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.
+ \item{label}{arbitrary text label for rule output, NULL
+ default will be converted to '<name>.rule'}
-The \code{name} parameter should be a character string naming the function
-to be called in the \code{\link{applyRules}} loop. The \code{add.rule}
-function will then call \code{\link{match.fun}}, ands store the actual function
-in your strategy object.
-This will avoid lookups via \code{\link{match.fun}} at \code{\link{applyRules}} time,
-and may provide a significant speed increase on higher frequency data (20\% or more).
+ \item{type}{one of
+ "risk","order","rebalance","exit","enter", see Details}
-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.
+ \item{...}{any other passthru parameters}
-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 \code{\link{ruleSignal}}, specifically the arguments \code{sigcol}
-and \code{sigval}. If these are present and function in a manner similar to
-\code{\link{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.}
-\arguments{\item{strategy}{an object of type 'strategy' to add the rule to}
-\item{name}{name of the rule, must correspond to an R function}
-\item{arguments}{named list of default arguments to be passed to an rule function when executed}
-\item{parameters}{vector of strings naming parameters to be saved for apply-time definition}
-\item{label}{arbitrary text label for rule output, NULL default will be converted to '<name>.rule'}
-\item{type}{one of "risk","order","rebalance","exit","enter", see Details}
-\item{...}{any other passthru parameters}
-\item{enabled}{TRUE/FALSE whether the rule is enabled for use in applying the strategy, default TRUE}
-\item{indexnum}{if you are updating a specific rule, the index number in the $rules[type] list to update}
-\item{path.dep}{TRUE/FALSE whether rule is path dependent, default TRUE, see Details}
-\item{timespan}{an xts/ISO-8601 style \emph{time} subset, like "T08:00/T15:00", see Details}
-\item{store}{TRUE/FALSE whether to store the strategy in the .strategy environment, or return it. default FALSE}}
+ \item{enabled}{TRUE/FALSE whether the rule is enabled for
+ use in applying the strategy, default TRUE}
+
+ \item{indexnum}{if you are updating a specific rule, the
+ index number in the $rules[type] list to update}
+
+ \item{path.dep}{TRUE/FALSE whether rule is path
+ dependent, default TRUE, see Details}
+
+ \item{timespan}{an xts/ISO-8601 style \emph{time} subset,
+ like "T08:00/T15:00", see Details}
+
+ \item{store}{TRUE/FALSE whether to store the strategy in
+ the .strategy environment, or return it. default FALSE}
+}
+\description{
+ Rules will be processed in a very particular manner, so
+ it bears going over.
+}
+\details{
+ First, rules are either path dependent or
+ non-path-dependent. Path dependent rules will be
+ processed in every time increment for the \code{mktdata}
+ passed into \code{\link{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 \code{type}. These may be any of:
+ \describe{ \item{risk}{ rules that check and react to
+ risk of positions, may stop all other rule execution
+ temporarily or permanently} \item{order}{ rules for order
+ processing of any open orders at time t, always
+ path-dependent} \item{rebalance}{ rules executed
+ specifically in a portfolio context, unnecessary in
+ univariate strategies} \item{exit}{ rules to determine
+ whether to exit a position} \item{enter}{ rules to
+ determine whether to enter or increase a position} } 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 \code{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 \code{name} parameter should be a character string
+ naming the function to be called in the
+ \code{\link{applyRules}} loop. The \code{add.rule}
+ function will then call \code{\link{match.fun}}, ands
+ store the actual function in your strategy object. This
+ will avoid lookups via \code{\link{match.fun}} at
+ \code{\link{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 \code{\link{ruleSignal}}, specifically the
+ arguments \code{sigcol} and \code{sigval}. If these are
+ present and function in a manner similar to
+ \code{\link{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.
+}
+
Modified: pkg/quantstrat/man/add.signal.Rd
===================================================================
--- pkg/quantstrat/man/add.signal.Rd 2011-08-09 21:09:10 UTC (rev 723)
+++ pkg/quantstrat/man/add.signal.Rd 2011-08-10 16:26:41 UTC (rev 724)
@@ -1,15 +1,41 @@
\name{add.signal}
\alias{add.signal}
-\title{add a signal to a strategy...}
-\usage{add.signal(strategy, name, arguments, parameters, label, ...,
- enabled=TRUE, indexnum, store=FALSE)}
-\description{add a signal to a strategy}
-\arguments{\item{strategy}{an object of type 'strategy' to add the signal to}
-\item{name}{name of the signal, must correspond to an R function}
-\item{arguments}{named list of default arguments to be passed to an signal function when executed}
-\item{parameters}{vector of strings naming parameters to be saved for apply-time definition,default NULL, only needed if you need special names to avoid argument collision}
-\item{label}{arbitrary text label for signal output, NULL default will be converted to '<name>.sig'}
-\item{...}{any other passthru parameters}
-\item{enabled}{TRUE/FALSE whether the signal is enabled for use in applying the strategy, default TRUE}
-\item{indexnum}{if you are updating a specific signal, the index number in the $signals list to update}
-\item{store}{TRUE/FALSE whether to store the strategy in the .strategy environment, or return it. default FALSE}}
+\title{add a signal to a strategy}
+\usage{
+ add.signal(strategy, name, arguments, parameters = NULL,
+ label = NULL, ..., enabled = TRUE, indexnum = NULL, store
+ = FALSE)
+}
+\arguments{
+ \item{strategy}{an object of type 'strategy' to add the
+ signal to}
+
+ \item{name}{name of the signal, must correspond to an R
+ function}
+
+ \item{arguments}{named list of default arguments to be
+ passed to an signal function when executed}
+
+ \item{parameters}{vector of strings naming parameters to
+ be saved for apply-time definition,default NULL, only
+ needed if you need special names to avoid argument
+ collision}
+
+ \item{label}{arbitrary text label for signal output, NULL
+ default will be converted to '<name>.sig'}
+
+ \item{...}{any other passthru parameters}
+
+ \item{enabled}{TRUE/FALSE whether the signal is enabled
+ for use in applying the strategy, default TRUE}
+
+ \item{indexnum}{if you are updating a specific signal,
+ the index number in the $signals list to update}
+
+ \item{store}{TRUE/FALSE whether to store the strategy in
+ the .strategy environment, or return it. default FALSE}
+}
+\description{
+ add a signal to a strategy
+}
+
Modified: pkg/quantstrat/man/addOrder.Rd
===================================================================
--- pkg/quantstrat/man/addOrder.Rd 2011-08-09 21:09:10 UTC (rev 723)
+++ pkg/quantstrat/man/addOrder.Rd 2011-08-10 16:26:41 UTC (rev 724)
@@ -1,96 +1,170 @@
\name{addOrder}
\alias{addOrder}
-\title{add an order to the order book...}
-\usage{addOrder(portfolio, symbol, timestamp, qty, price, ordertype, side,
- threshold, status="open", statustimestamp="", delay=1e-05,
- tmult=FALSE, replace=TRUE, return=FALSE, ..., TxnFees=0)}
-\description{add an order to the order book}
-\details{It is important to understand that all the order functionality included in \code{quantstrat}
-exists to more closely model a real trading environment both in backtesting and in production.
-Many backtesting systems make a set of assumptions about instant execution,
-and we have chosen not to do this in quantstrat, because real quantitative
-trading systems do not have instant execution. They make decisions
-(the Rules) and then enter orders (the province of this function in backtesting),
-during which there is some \code{delay} between receiving the data that fires the
-Signal and Rule, and the time the order reaches the market, and then those orders
-\emph{MAY} become transactions if market prices and liquidity cooperate.
+\title{add an order to the order book}
+\usage{
+ addOrder(portfolio, symbol, timestamp, qty, price,
+ ordertype, side, threshold = NULL, status = "open",
+ statustimestamp = "", delay = 1e-05, tmult = FALSE,
+ replace = TRUE, return = FALSE, ..., TxnFees = 0)
+}
+\arguments{
+ \item{portfolio}{text name of the portfolio to associate
+ the order book with}
-By default, this function will locate and replace any 'open' order(s)
-on the requested portfolio/symbol that have the same type and side.
-This is the equivalent of what is sometimes called an
-OCO (Order Cancels Other) order. If you do not want the function to
-behave this way, set \code{replace=FALSE}.
+ \item{symbol}{identfier of the instrument to find orders
+ for. The name of any associated price objects (xts
+ prices, usually OHLC) should match these}
-We have modeled two types of stop orders, which should be sufficient to model most types of stops.
+ \item{timestamp}{timestamp coercible to POSIXct that will
+ be the time to search for orders before this time}
-We have modeled the simplest type, a 'stoplimit' order, which is just a limit order used to enter
-or exit a position at a specific price.
-Threshold multipliers have also been added for stoplimit. These allow a threshold to be set as a multiplier
-of the current price. For example, to set a stoplimit order at the current price
-plus ten percent, you would set the threshold multiplier to 1.10. The threshold multiplier (or scalar) on a
-stoplimit order will be converted to a price at order entry.
-There is no functional different between a regular 'limit'
-order and a 'stoplimit' order once entered into the order book, but the distinction will likely
-be useful for reporting on when stops have been triggered.
+ \item{qty}{numeric quantity of the order}
-We have also modeled a 'stoptrailing' order, which may be used to model dynamic limit-based entry or exit.
-If you set \code{tmult=TRUE} on a stoptrailing order, the size of the threshold will be set as a
-difference between the multiplier times the price and the current price at order entry. in this way, a 10%
-trailing entry (exit) will not change in size from the current price as the price changes. It is effectively
-converted to a scalar at order entry. While this functionality could change in the future,
-we believe this is more conservative than growing or shrinking the threshold distance from the current market price
-in relation to the threshold, and will result in fewer unintended consequences and more understandable behavior. Comments Welcome.
+ \item{price}{numeric price at which the order is to be
+ inserted}
-The 'stop*' or 'iceberg' order types are the only order type that makes use of the order \code{threshold}.
-Scalar thresholds \code{tmult=FALSE} on stoplimit or stoptrailing
-orders will be added to the current market price to set the limit price. In other worlds, a
-scalar threshold is the difference either positive or negative from the current price when
-the order is entered. With a stoptrailing order, the order may be moved (via cancel/replace) frequently.
+ \item{ordertype}{one of "market","limit","stoplimit",
+ "stoptrailing",or "iceberg"}
-Some markets and brokers recognize a stop that triggers a market order, when the stop is triggered,
-a market order will be executed at the then-prevailing price. We have not modeled this type of order.
+ \item{side}{one of either "long" or "short"}
-We have also added the 'iceberg' order type. This order type should
-most often be paired with \code{delay} and \code{\link{osMaxPos}}. The
-iceberg order when initially entered is treated like a limit
-order, with an optional threshold (which is applied at initial order
-entry, so be careful). Right now, they will enter a new order at price+threshold
-upon any execution of the prior iceberg order. This process could
-be infinite if \code{\link{osMaxPos}} or an equivalent order sizing
-function is not used to limit total position size. An order \code{delay}
-is also advisable to model the delay that occurs between getting the trade
-confirmation of the previous trade and entering the new order into the order book.
+ \item{threshold}{numeric threshold to apply to trailing
+ stop orders, default NULL}
-If you ever wanted to move from a backtesting mode to a production mode,
-this function (and the linked funtion \code{\link{ruleOrderProc}}) would
-need to be replaced by functions that worked against your execution environment.
-Basically, the execution environment must provide three interfaces in a live
-trading environment:
+ \item{status}{one of "open", "closed", "canceled", or
+ "replaced", default "open"}
-\enumerate{
-\item a market data interface to provide updated market data, usually accessed in an event loop
+ \item{statustimestamp}{timestamp of a status update, will
+ be blank when order is initiated}
-\item an order interface for sending orders (and canceling or updating them) to the market
+ \item{delay}{what delay to add to timestamp when
+ inserting the order into the order book, in seconds}
-\item a fill interface that reports the transaction details when an order has been filled
+ \item{tmult}{if TRUE, threshold is a percent multiplier
+ for \code{price}, not a scalar to be added/subtracted
+ from price. threshold will be dynamically converted to a
+ scalar at time of order entry}
+
+ \item{replace}{TRUE/FALSE, whether to replace any other
+ open order(s) on this portfolio symbol, default TRUE}
+
+ \item{return}{if TRUE, return the row that makes up the
+ order, default FALSE (will assign into the environment)}
+
+ \item{\dots}{any other passthru parameters}
+
+ \item{TxnFees}{numeric fees (usually negative) or
+ function name for calculating TxnFees (processing happens
+ later, not in this function)}
}
+\description{
+ It is important to understand that all the order
+ functionality included in \code{quantstrat} exists to
+ more closely model a real trading environment both in
+ backtesting and in production. Many backtesting systems
+ make a set of assumptions about instant execution, and we
+ have chosen not to do this in quantstrat, because real
+ quantitative trading systems do not have instant
+ execution. They make decisions (the Rules) and then
+ enter orders (the province of this function in
+ backtesting), during which there is some \code{delay}
+ between receiving the data that fires the Signal and
+ Rule, and the time the order reaches the market, and then
+ those orders \emph{MAY} become transactions if market
+ prices and liquidity cooperate.
+}
+\details{
+ By default, this function will locate and replace any
+ 'open' order(s) on the requested portfolio/symbol that
+ have the same type and side. This is the equivalent of
+ what is sometimes called an OCO (Order Cancels Other)
[TRUNCATED]
To get the complete diff run:
svnlook diff /svnroot/blotter -r 724
More information about the Blotter-commits
mailing list