You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The requirements for the state machine project are:
to be able to handle real-time and historical data events coming in up to one minute frequency. This relaxes some of the requirements and complexity compared to typical high frequency trading (HFT) systems.
Vectorized version will still be available... In quantstrat you have path-dependent (i.e. event-driven) and non-path-dependent (i.e. vectorized) option, but only path-dependent one works... So even if you have a simple strategy where a vectorised version would do the trick, quantstrat still goes through the slow, main event-driven loop... Keep and enhance vectorised version in parallel with event based state machine one.
List of external orientation resources, in addition to understanding current strategery infrastructure. Suggestion is to read the list in the order as below:
quantstrat package - the only existing event-driven backtester in R that I know of. It is poorly implemented performance-wise and code complexity-wise I opine, but has almost all the functionality that I aim to use. They use callback model I think (not transition table).
SIT package in R (a.k.a. Systematic Investor Toolbox) - A research-driven, vectorized backtesting framework. See Michael Kapler's blog or github project page
other relevant R packages, namely data.table, TTR, quantmod, PerformanceAnalytics, blotter, quantstrat, SIT , fInstruments (RMetrics), FinancialInstrument
Think of investment portfolio as a vending machine managing inventory. Our machine is bit more complicated: it buys and sells items following user-specified trading rules, maintains inventory stats and tracks resulting profit/loss). But analogy with vending machine is helpful. See: http://sourcemaking.com/design_patterns/state
The requirements for the state machine project are:
List of external orientation resources, in addition to understanding current
strategeryinfrastructure. Suggestion is to read the list in the order as below:http://www.quantstart.com/articles/Best-Programming-Language-for-Algorithmic-Trading-Systems
http://www.quantstart.com/articles/Choosing-a-Platform-for-Backtesting-and-Automated-Execution
http://www.r-programming.org/papers
This is the key resource: Part I-VII of http://www.quantstart.com/articles/Event-Driven-Backtesting-with-Python-Part-I. I have full source code in Python for complete state machine model. Can share it via mail.
twppackage (Trading With Python, by Jev Kuznetsov) source: https://code.google.com/p/trading-with-python/source/browse/trunk/lib/[ ]
http://cran.r-project.org/web/packages/IBrokers/vignettes/RealTime.pdf
quantstratpackage - the only existing event-driven backtester in R that I know of. It is poorly implemented performance-wise and code complexity-wise I opine, but has almost all the functionality that I aim to use. They use callback model I think (not transition table).SIT package in R (a.k.a. Systematic Investor Toolbox) - A research-driven, vectorized backtesting framework. See Michael Kapler's blog or github project page
other relevant R packages, namely
data.table,TTR,quantmod,PerformanceAnalytics,blotter,quantstrat,SIT,fInstruments(RMetrics),FinancialInstrumentThink of investment portfolio as a vending machine managing inventory. Our machine is bit more complicated: it buys and sells items following user-specified trading rules, maintains inventory stats and tracks resulting profit/loss). But analogy with vending machine is helpful. See: http://sourcemaking.com/design_patterns/state
Another implementation I've seen is this: http://premium.working-money.com/wm/display.asp?art=532. I think tracking portfolio states is better approach than tracking buy/sell states as described here.
Another inspiration: http://eng.wealthfront.com/2012/10/developing-portfolio-backtester-in-r.html