we tried to make it run for pairstrading. finding a cointegrated basket of n-stocks and trading the outliers against each other. did not work really well, found something different, traded that. it is a while back now and we implemented everything in C++ on our own and yes, it did not take year, but it was some months in total. and i must add that we set up all our pairstrading at that time. your comparison with guys walking is nice, though i'd say it is more to find a third guy who is always in between the two ... well maybe not always "in between".
As long as your third guy is making money, that's what you want! About using C++ for mathematics (or other languages for that matter): "Language Development is Library Development and Library Development is Language Development" (A Bell Labs proverb as quoted by Stroustrup - not sure he was thinking about our usage though) My experience is that searching for the right libraries is precious in mathematics. Hard to improve upon and avoiding incredibly long debug times. In many cases, I found MathLab to be a nice toy but only a toy.
we are using S+, more precisely R, just because someone i hired preferred it and we sticked to it ever since. my C++ guy has a tough time with me, since the whole implementing process is always too slow for me. it is never as easy as you think it is in the first place. just thinking about how long it takes until we have something new really on trading. i love our IT-stability, but i hate when we "waste" time with non-strategyDevelopment issues. i truly hate that.
Nice, man! I did a lot of S Plus 2000 till a couple of years ago. I'm also in R now. I share your hate of "waste time". I use exclusively Python right now falling back on rpy. Very nice. You get the speed of R with the flexibility - read development speed - of Python in "sewing" it all together. http://rpy.sourceforge.net/
funny! matlab is much more common around quant traders ... the problem with R has always been for us the poor cache management. on intraday data that sucks a lot. we use it on macs (=unix based), which is better than DOS (still love to call it by that ... ) ... but still. we have a backtesting "platform" in C++ and in R parallel. in addition we sometimes do little things in excel and tradestation. it is really funny, none of these tools tops the others in all aspects ... whenever we do something more sophisticated we love to check it in R, since cointegration&friends are easily at hand. plus i love the R graphics ... a pain to do in C++ ...
(1) from C/C++ with R, things should always run the fastest if done in a competent way; (2) Python, in fact builds on C, is unbeatable for development time. Don't want to get into this but figures of 10 times reduction in development time are often advanced. It is a fact that running time in many mathematical problems is determined by very few lines of highly repetitive code. This is typically what sits in the R libraries. So using Python with rpy R wrappers is nor penalizing you significantly. In fact, talking languages, it is amazing that some R components do fall back on Fortran code. http://www.python.org/ http://groups.google.com/group/comp.lang.python?lnk=gschg&hl=en Now don't read me wrong. Making good money doesn't always require lots of mathematics. Handy to know about it, but you need only to use just what you truly need. ( ) Be good, nononsense
my experience is that a good coder will usually prefer to work as low within the environment as possible. and (s)he will do most of time things faster if you look at project as a whole. what you might win with more easy to use dragAndChopAndHopDiHop in the first place, you will often loose when it comes to the ifs and whens in the real world output ... bugs and interpretation and understanding what is really going on ... that kind of thing.