If you find some I would sure like to hear from you. I'll start on this project some time this week. Kind regards Espen
Quit being a meanie vibrator. OP: The C# code in my cointegration collection is from vanna's posts on quantcode. Sorry for the false alarm. My observation has been that source code on the interwebs like vanna's is usually written by non-programmers and academics. As a result it's very hard to tease out the core algorithm code since it's usually all mixed up with GUI support etc. Like you I've searched and searched for a simple function call library to do this analysis and concluded I'd have to write it myself when I got time. Since cointegration analysis is not one of my current priorities I haven't done it yet.
I do not intend to be mean to the OP but sometimes the time they spend to put up such post and read all the responses takes longer than simply pulling out their stats/econometric text books and simply translate into program code. We are talking about cointegration which is hardly more complex than most other basic time series and econometric material. And by the way, there are multiple approaches to test for and quantify cointegration, so its a moot point to ask for THE ONE code, because there is not just one approach.
I didn't read all of the posts so I don't know if this already suggested or not, but why not use a R wrapper for C#? If your strategy isn't extremely latency sensitive (I suspect it's not otherwise you wouldn't be using c# to begin with) then it's a fairly reasonable approach. R.NET http://rdotnet.codeplex.com/ I disagree here, if you can find the code elsewhere and it's been tested there's no reason not to do use it. You save yourself brain damage and also dev time. Unless you have some very special requirement of course.
Building cointegration tests is hard for mere mortals, and non-phds, despite what calvibrator says. One way is to hook into R, and re-use a Dickey Fuller test there, as a batch you can call from another language. Calculate your relationships offline, use the results online.
Using the R wrapper is EXTREMELY slow, you can't possibly say C# is already slow so it does not make a difference whether or not to use the R.Net library. And C# is in many regards fast enough even for latency sensitive applications, other than >= hft in the milliseconds. I just heard that Societe General is re-writing its entire global front office pricing library code-base, guess in which language: C#. Re using open source, tested, code, applications...: Fully agree with you, and that is why the OP should have done a quick Google search because he would have found what he is looking for.
what the heck are you talking about. You do not need to have a PhD to run a simple co-integration test. Seriously, if you find this a challenge then you better stick to punting stocks as day trader. Engle-Granger, Dickey Fuller, Johansen tests are very straightforward and very simple to model. Again, I recommend you yourself picking up a simple econometrics text book and read up before you make dumb claims.
I agree that C# is great for handling the business end of things and almost everything else but HFT. Wasn't aware that it's extremely slow, however I suppose it also depends on what your definition of slow is right? Suppose it takes a few seconds for this thing to run, that's ages for someone doing something latency sensitive but might be meaningless for someone else. I think you're mistaken, they're pretty trivial to implement.