If you want to backtest in R, your best bet is to use the quantstrat set of libraries (https://r-forge.r-project.org/scm/viewvc.php/pkg/quantstrat/?root=blotter).
Feel free to PM me for more info.
Feel free to PM me for more info.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
R for datamining/backtesting/trading
- Thread starter caementarius
- Start date
Quote from johnnyqpublic:
If you want to backtest in R, your best bet is to use the quantstrat set of libraries (https://r-forge.r-project.org/scm/viewvc.php/pkg/quantstrat/?root=blotter).
Feel free to PM me for more info.
Thanks, I appreciate you pointing that out. I have looked at it. The challenge is building something that you don't have to rewrite in order to deploy in an event-driven fashion (responding to new bars or ticks as they arrive).
But - I had a kind of "well, duh" idea.
I suppose if a strategy is not high frequency and operates say once per minute, you could just update the historical data with a new minute bar each minute, rerun your backtest on however much data you need to go back through, and see if any new signals were generated since the last test. This way you don't need to convert your backtest strategy into an event-driven strategy that is keeping track of states.
This could be practical for a medium-frequency bot or greybox. The bot just collects bars, updates bar data in R and adjusts backtest timeframe, runs the backtest and checks for signals/orders.
Anyone approach it like that?
Quote from caementarius:
I suppose if a strategy is not high frequency and operates say once per minute, you could just update the historical data with a new minute bar each minute, rerun your backtest on however much data you need to go back through, and see if any new signals were generated since the last test. This way you don't need to convert your backtest strategy into an event-driven strategy that is keeping track of states.
This could be practical for a medium-frequency bot or greybox. The bot just collects bars, updates bar data in R and adjusts backtest timeframe, runs the backtest and checks for signals/orders.
Anyone approach it like that? [/B]
That sounds terrible.
Can you actually code? (C#,C++ whatever?)
Quote from caementarius:
... Has anyone made R their "home" for everything (mining+testing+live signals)? Or - If you've been down the same road building your own tools for the whole process, what technologies did you settle on?
I don't trade with R, but it's part of my Research&Development (above referred to as "mining" or "exploration" ... I like that!) tool kit.
I'm a systematic trader and now use:
a database (of ticks or more)
+
C# or Python (to look for whatever structure I'm interested in)
+
R (to analyse the resulting data)
I don't know how to program so everyday for my swingtrading system after the close of the market I run my systems manually to see if they trigger. I wish this could be automated.
Quote from caementarius:
I've used a few platforms for strategy development. I always seem to come up against obstacles where I might as well write my own stuff rather than go through the gymnastics to get what I want out of the platform. For example, NinjaTrader felt weird to try to access more than 1-2 securities prices at a time (needed to wrap them into a derived indicator, if I remember correctly). With tradelink, not everything worked out of the box - so there was tweaking to be done plus data management was clunky.
With R/quantmod and other modules, there is some nice open-source work mostly approached from an academic angle.
The academic angle uses vector operations and can make for some nice succinct functional code. See this backtest in just a few lines of R script:
http://blog.fosstrading.com/2011/03/how-to-backtest-strategy-in-r.html
But, using vector operations isn't great when you want to switch to an event-driven model that responds to new bars or new ticks - like what happens when you want to run on live data and generate signals. And, more path-dependent trade logic expands the number of vectors needed until it's more messy than it's worth. The nice thing about NT and tradelink is that they are built from the ground up to run the same code whether you are backtesting or running live.
Overarching all of this is my belief that I am likely better served developing systems by first exploring relationships in data and then seeing what might be a trade.
So, I think R might be the way - but when I use it, iterating over bar data, it feels like I'm doing it wrong by introducing flow control into a functional language.
Has anyone made R their "home" for everything (mining+testing+live signals)? Or - If you've been down the same road building your own tools for the whole process, what technologies did you settle on?
I use R for analysis and some back testing, mostly prototyping new ideas and checking stats. Then I move to my python + mysql "platform" to do another level of prototyping / back-testing. Finally, I code up the best ideas for forward testing / live trading into a custom lightweight java program implemented via the IB TWS Java API. It sounds cumbersome, but it's actually a lot faster than investing huge amounts of time building a monolithic package. The problem with using 3rd party platforms is that they lack flexibility, and if you try to implement something off the beaten path, you end up struggling to fit a square peg into a round hole. On the other hand building a custom huge platform to me is a waste unless you are completely decided on your strategies because you could end up investing years in it and find out that what you originally had in mind doesn't work well. So prototyping is the way to go for me -- it really lets me keep testing ideas that our outside of the box (or platform) so to speak. Another key attitude that keeps me making progress is to not fall into the trap of trying to make everything absolutely elegant and beautiful. To me, that's a total waste of time unless you have found the holy grail already. But that's just my philosophy.
Quote from ssrrkk:
I use R for analysis and some back testing, mostly prototyping new ideas and checking stats. Then I move to my python + mysql "platform" to do another level of prototyping / back-testing. Finally, I code up the best ideas for forward testing / live trading into a custom lightweight java program implemented via the IB TWS Java API. It sounds cumbersome, but it's actually a lot faster than investing huge amounts of time building a monolithic package. The problem with using 3rd party platforms is that they lack flexibility, and if you try to implement something off the beaten path, you end up struggling to fit a square peg into a round hole. On the other hand building a custom huge platform to me is a waste unless you are completely decided on your strategies because you could end up investing years in it and find out that what you originally had in mind doesn't work well. So prototyping is the way to go for me -- it really lets me keep testing ideas that our outside of the box (or platform) so to speak. Another key attitude that keeps me making progress is to not fall into the trap of trying to make everything absolutely elegant and beautiful. To me, that's a total waste of time unless you have found the holy grail already. But that's just my philosophy.
Very insightful post. Appreciate it. I worry about model risk in moving from one framework to another - but I think your way might be most practical.
Quote from ssrrkk:
I use R for analysis and some back testing, mostly prototyping new ideas and checking stats. Then I move to my python + mysql "platform" to do another level of prototyping / back-testing.
Agree with the approach overall - in my experience, being able to quickly test a novel idea far outweighs the disadvantages of having to develop/maintain an additional code base for live trading (which very rarely changes).
I've never used Python...if you have a minute, would be interested to get your take on what it does better / worse than R that makes it worthy of inclusion in your process.