9
$\begingroup$

I am interested in coding a medium frequency (trading over minutes to hours, holding for days to weeks) quantitative trading strategy and trading it with Interactive Brokers.

I have seen many people here mention that they use Matlab (or R, SAS, etc.) for strategy development/backtesting, but that they would prefer to program the execution code for live trading in C++/C#/Java. What are the advantages of re-coding the strategy into a lower-level language and/or the disadvantages of maintaining the same platform for strategy development and implementation?

My thinking is that keeping the same platform allows one to easily incorporate updates and improvements to the strategy over time, whereas the IBrokers package and various commercial Matlab tie-ins to IB's API make it feasible to communicate directly with IB from the development platform. Is there something I am missing here? Have others tried this?

Improve this question
$\endgroup$
3
  • 1
    $\begingroup$ I take "real-time trading" to mean tick-level data, not one-minute aggregates. You'll be fine with Matlab. By the way, this question gets asked a lot [ 1, 2, 3, 4 ]. $\endgroup$
    – chrisaycock
    Jul 21, 2011 at 22:26
  • $\begingroup$ It does not necessarily mean tick-level data, since for a medium frequency strategy it may be enough to get updates every 15, 30 seconds, or whatever, if the tick frequency is very high. I also suspect I'll be fine with Matlab, but the question is whether I am missing anything? $\endgroup$
    – Tal Fishman
    Jul 21, 2011 at 22:50
  • $\begingroup$ I also looked at each of those other questions, and others, and I do not think any directly address the question of using one versus two languages/platforms for the two stages of development of the same strategy. Most previous questions discuss the relative merits of a complete switch. The closest one is this, but there the focus is more on performance and efficiency, which are less important for medium frequency trading. $\endgroup$
    – Tal Fishman
    Jul 21, 2011 at 22:52

5 Answers 5

Reset to default
10
$\begingroup$

This is an evergreen. I've been discussing this with many people - without any clear-cut conclusion. The answer and the preferred solution depend on your trading style (e.g. frequency), your skills, the size of the team, and many other factors.

For simplicity, I call "Research" the Matlab/R/etc. environments, whereas "Live" refers to the re-programmed C++/Java/C# environments.

The proponents of reprogramming usually claim that the two environments are very different in nature, namely:

  • Robustness: Research is ad-hoc-ish by nature, your main concern is not speed, programming robustness and style. Production needs to be more robust and faster, and you want to reuse components such as e.g. a price stream.
  • Data Research is usually done on a closed data-set: you have a set of in-sample data and wherever possible, you're running backtests with matrix functions (e.g. in Matlab or R). In live trading, you are working on incremental data, new information is popping in irregular spacing. Thus, live trading is much more event-driven (at least for higher frequencies).
  • Assumptions In a backtest, you need to make assumptions on the fill ratio and price, and very often you calculate positions asymptotically (i.e. as a percentage of your portfolio, regardless of the minimum size you can hold of a position). In live trading, you can't do that. You need to generate an order in terms of size of futures/shares/etc. Also, you will need to feed back in your actual position (which depends on the fills you got), which is something you don't have to worry about in research.

People usually try to overcome these differences with different strategies, such as:

  • The Python way take the middle route by building everything in a high-level language that possibly fits both requirements. The opponents of this strategy claim that this way you won't end up with best-of-breed solutions, neither in research nor in live trading.

  • The Matlab/R way Research-centric shops try to build everything around Matlab. In my experience, this works well to a certain size, but with larger teams things can get very difficult to maintain. Re-usability of components among the team can become very difficult.

  • The Reprogramming This requires either very good skills or a dedicated re-programming team. This is usually expensive and difficult, and the risk is to add errors.

  • Integration There are some platforms that allow you to deploy strategies in multiple languages (e.g. compiled matlab code, R automation, etc.). If done well, this may be the best solution.

For yourself, if you're the only one working on the strategy, and with the frequency you mention, the The Matlab/R way sounds like the way to go.

Improve this answer
$\endgroup$
7
$\begingroup$

The only benefits I can imagine from re-coding in C++ would be speed. But speed doesn't seem to be a concern for your time horizon (especially if you write efficient Matlab code). Some may argue that C++ is more stable, but Matlab is plenty stable for live trading.

However, the downsides of using two languages are even more significant than just ease of updating and improving the strategy. Not only do you have to code new updates twice, but C++ and Matlab aren't that similar, so you'll have to write different code. This will dramatically increase your chance of making errors, which will more than likely lose you money.

Ultimately, unless you're at the point where speed is critical, having two different code bases for development and implementation is a nightmare.

Improve this answer
$\endgroup$
1
  • $\begingroup$ You are right that speed is not a concern, and I am aware that there are plenty of other downsides besides those I mentioned. I am looking to flesh out the disadvantages before I commit to using the same language for implementation. $\endgroup$
    – Tal Fishman
    Jul 29, 2011 at 18:11
3
$\begingroup$

You could combine both languages into one platform. I use Octave a lot ( the open source equivalent of MATLAB ) and where speed is an issue I have re-written .oct functions in C++ that are called from Octave. This has the advantage of using just Octave code for functional day to day use but with the speed of C++ where necessary.

Improve this answer
$\endgroup$
1
  • $\begingroup$ That's where Rcpp came from in the R and C++ hybrid. I used to write .oct files too but generally prefer R over Octave/Matlab now. $\endgroup$
    – Dirk Eddelbuettel
    Feb 2, 2012 at 0:06
3
$\begingroup$

There is no advantage. You will introduce new bugs. It's a basic fact of software writing. Just by wishing they weren't there you don't make bugs go away.

A few years ago, I had a job (at medium to high frequency) where all code morphed from research / development to production, often with a translation. It was a huge issue, even at that rather advanced firm.

My next job was higher/highest frequency where things happened in C++ only. So to do more higher-level analysis in R, I needed to bring R and C++ closer together. Rcpp makes that possible.

Now, language choice is both personal (style, what you may have learned first, ...) and institutional (whatever the shop has settled on) so this pairing can't and won't work for everyone. But it did for me, and largely because it alleviated the split between research software and trading software. These were the same C++ routines, simply deployed in different contexts.

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ I agree. Rewriting software will only ever introduce new bugs. That's why I wish I could have a statically typed version of q, so I could get performance closer to C++ but in a more productive environment. $\endgroup$
    – chrisaycock
    Feb 2, 2012 at 0:41
2
$\begingroup$

I am still researching this topic more fully, but so far I have found the following advantages to re-coding the strategy in a lower level language (for better or worse, my language of choice in this case is Java):

  1. Access to the latest API. R's IBrokers doesn't implement all of the IB API's latest features, and there is no guarantee that the package will be kept up-to-date. I do not like relying on a commercial vendor for a Matlab interface to IB, and most of the developers of these interfaces would lead you to believe that setting it up is no trivial matter.
  2. Personalized trading front-end/GUI. Both R and Matlab's GUI capabilities leave much to be desired. Java's Swing is a joy to use.
  3. Multi-threading. Although parallel processing has been built into R, and Matlab somewhat if you are willing to pay for it, both were designed as fundamentally single-threaded languages.
  4. Ability to call R/Matlab code from Java. I am as yet unsure as to how well this would work, but it at least seems possible to directly use much of the strategy code I've already built by calling an instance of Matlab from Java.

Help or further advice on this topic would still be greatly appreciated.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.