[Blotter-commits] r430 - in pkg/quantstrat: R man

noreply at r-forge.r-project.org noreply at r-forge.r-project.org
Mon Oct 25 14:46:20 CEST 2010


Author: braverock
Date: 2010-10-25 14:46:19 +0200 (Mon, 25 Oct 2010)
New Revision: 430

Modified:
   pkg/quantstrat/R/orders.R
   pkg/quantstrat/R/rules.R
   pkg/quantstrat/man/add.rule.Rd
   pkg/quantstrat/man/ruleOrderProc.Rd
Log:
- add argument handling for 'prefer' argument to address R-Forge request 1146 for Mark Breman
- update docs

Modified: pkg/quantstrat/R/orders.R
===================================================================
--- pkg/quantstrat/R/orders.R	2010-10-25 12:23:05 UTC (rev 429)
+++ pkg/quantstrat/R/orders.R	2010-10-25 12:46:19 UTC (rev 430)
@@ -351,6 +351,7 @@
 
 #' process open orders at time \emph{t}, generating transactions or new orders
 #' 
+#' The ruleOrderProc function is effectively the default fill simulator for quantstrat. 
 #' This function is meant to be sufficient for backtesting most strategies, 
 #' but would need to be replaced for production use.  It provides the interface 
 #' for taking the order book and determining when orders become trades.
@@ -363,12 +364,25 @@
 #' system, first stop (flatten), and then reverse (initiate a new position).
 #' 
 #' This function would need to be revised or replaced for connection to a live trading infrastructure.
+#' In a production mode, you would replace the \code{\link{addOrder}} function 
+#' with a custom function to connect to your market infrastructure.  
+#' In that case, you might need to add additional code to your strategy, 
+#' or overload functions for checking position.  
+#'   
+#' Note that this function is called by default in the 'orders' slot of the 
+#' \code{\link{applyRules}} processing.  If you have defined another order 
+#' processing rule, it with \emph{replace} this function.  If you want your 
+#' custom order rule and ruleOrderProc to both be called, you will need
+#' explicitly add a rule to call ruleOrderProc either before or after your 
+#' custom order processing function. 
 #' 
 #' We would like to model slippage here via \code{slippageFUN}.  Code contributions, suggestions, 
 #' and requests appreciated. 
-#'    
+#'
+#' @concept fill simulator
+#' @concept orders  
 #' @param portfolio text name of the portfolio to associate the order book with
-#' @param symbol identfier of the instrument to find orders for.  The name of any associated price objects (xts prices, usually OHLC) should match these
+#' @param symbol identfier of the instrument to find orders for.  The name of any associated price objects (xts prices, usually OHLC or BBO) should match these
 #' @param mktdata an xts object containing market data.  depending on indicators, may need to be in OHLCV or BBO formats, default NULL
 #' @param timespan xts-style character timespan to be the period to find orders to process in
 #' @param ordertype one of NULL, "market","limit","stoplimit", or "stoptrailing" default NULL

Modified: pkg/quantstrat/R/rules.R
===================================================================
--- pkg/quantstrat/R/rules.R	2010-10-25 12:23:05 UTC (rev 429)
+++ pkg/quantstrat/R/rules.R	2010-10-25 12:46:19 UTC (rev 430)
@@ -31,7 +31,7 @@
 #' 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 documentatioon) from 
+#' 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. 
 #' 
@@ -174,6 +174,9 @@
             }
 
             .formals  <- formals(fun)
+            
+            if(hasArg(prefer)) .formals$prefer=match.call(expand.dots=TRUE)$prefer
+            
             onames <- names(.formals)
             rule$arguments$timestamp = timestamp
 			rule$arguments$ruletype  = ruletype
@@ -196,7 +199,7 @@
                 .formals[pm] <- nargs[pm > 0L]
             }
             .formals$... <- NULL
-
+            
             tmp_val<-do.call(fun,.formals)
             ## if(!is.null(tmp_val)){
             ##     if(is.null(names(tmp_val)) & ncol(tmp_val)==1) names(tmp_val)<-rule$label

Modified: pkg/quantstrat/man/add.rule.Rd
===================================================================
--- pkg/quantstrat/man/add.rule.Rd	2010-10-25 12:23:05 UTC (rev 429)
+++ pkg/quantstrat/man/add.rule.Rd	2010-10-25 12:46:19 UTC (rev 430)
@@ -36,7 +36,7 @@
 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 documentatioon) from 
+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. 
 

Modified: pkg/quantstrat/man/ruleOrderProc.Rd
===================================================================
--- pkg/quantstrat/man/ruleOrderProc.Rd	2010-10-25 12:23:05 UTC (rev 429)
+++ pkg/quantstrat/man/ruleOrderProc.Rd	2010-10-25 12:46:19 UTC (rev 430)
@@ -4,7 +4,8 @@
 \usage{ruleOrderProc(portfolio, symbol, mktdata, timespan, ordertype, ...,
     slippageFUN)}
 \description{process open orders at time \emph{t}, generating transactions or new orders}
-\details{This function is meant to be sufficient for backtesting most strategies, 
+\details{The ruleOrderProc function is effectively the default fill simulator for quantstrat. 
+This function is meant to be sufficient for backtesting most strategies, 
 but would need to be replaced for production use.  It provides the interface 
 for taking the order book and determining when orders become trades.
 
@@ -16,11 +17,24 @@
 system, first stop (flatten), and then reverse (initiate a new position).
 
 This function would need to be revised or replaced for connection to a live trading infrastructure.
+In a production mode, you would replace the \code{\link{addOrder}} function 
+with a custom function to connect to your market infrastructure.  
+In that case, you might need to add additional code to your strategy, 
+or overload functions for checking position.  
 
+Note that this function is called by default in the 'orders' slot of the 
+\code{\link{applyRules}} processing.  If you have defined another order 
+processing rule, it with \emph{replace} this function.  If you want your 
+custom order rule and ruleOrderProc to both be called, you will need
+explicitly add a rule to call ruleOrderProc either before or after your 
+custom order processing function. 
+
 We would like to model slippage here via \code{slippageFUN}.  Code contributions, suggestions, 
 and requests appreciated.}
+\concept{fill simulator}
+\concept{orders}
 \arguments{\item{portfolio}{text name of the portfolio to associate the order book with}
-\item{symbol}{identfier of the instrument to find orders for.  The name of any associated price objects (xts prices, usually OHLC) should match these}
+\item{symbol}{identfier of the instrument to find orders for.  The name of any associated price objects (xts prices, usually OHLC or BBO) should match these}
 \item{mktdata}{an xts object containing market data.  depending on indicators, may need to be in OHLCV or BBO formats, default NULL}
 \item{timespan}{xts-style character timespan to be the period to find orders to process in}
 \item{ordertype}{one of NULL, "market","limit","stoplimit", or "stoptrailing" default NULL}



More information about the Blotter-commits mailing list