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?
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.
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.
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.