Journal entry Thoughts on my system Ideally, I would like to ignore whatever is going on in the market in my yet-to-be-developed system, but my time at the hedge fund showed me that politics is a big driver of trading profits. I may not be able to avoid this forever, but perhaps I can eke out small success before going for the big trades. Education The education on Quantopian is progressing nicely. Currently up to lecture #4. Although I had heard about Jupyter/IPython notebooks before, and even messed around a bit, they seem to be pretty powerful. Until now, I have used Org-mode in Emacs to accomplish the same goals. Interesting things happening in the Python space for finance. Pandas is a ridiculously expressive library for data manipulation. I can see it being very useful for developing systems in a repeatable fashion. I'm hopeful that the remainder of the lecture series is as high quality as what I've seen so far. Note: Until I actually start developing or testing a system, I will update this journal once a week on Saturday mornings to chronicle my progress thus far. This will help keep the noise down on this thread
I think it was API 7.1 (or 7.3) where they made many breaking and significant changes to their .NET C# API, for example. But that was only lower level tech changes such as different socket logic, disconnect logic, threading issues... But most importantly, IB implements new API functions with many new API version. How else would they promote the usage of new features if they are not usable. Anyone who wrote a wrapper would need to constantly keep pace with those new versions, unless of course all you rely on is Market, Limit, Stop orders, fill call backs, and account updates. Also the wrappers may stop working altogether if IB changes something in the core logic and the wrapper has not been updated since.
Can you tell me about a time when these features have made you significant amount of money? I'm just curious about the types of things I should be looking for. One other thing, is how do you do any back testing when you're using the connector directly? I'm presuming that you have your own wrapper around it that allows you to back test? Thank you.
Pre the latest version of the API you couldn't call the API directly from python so you needed some kind of wrapper around one of the supported APIs. And yes, there was no reason to do this yourself. There were at least two solutions which worked pretty well. They did have the disadvantage that others have pointed out. Personally I'd rather not do this: put an extra intermediate layer of someone elses code in a critical part of my system. I only did it because I had no choice, So now there is a native python API, why not call it? Why use a "wrapper". It depends what you mean by "adaptor" / "wrapper". What does an adaptor / wrapper do? What advantages does it have? Disadvantages are obvious - lack of support, getting stale w.r.t. official API (as discussed), potential latency, unknown bugs. Advantages are possibly: hiding some of the complexity of the API from the user, perhaps making it more 'pythonic' Possibly providing a solution to shrink wrap and hide the basically event driven nature of the code Providing a whole load of extra framework, up to and including an entire automated system to which you just need to add the signals. 1 and 2 might have some value, but the API isn't THAT complex, and I do feel that anyone doing fully automated trading needs to have some understanding of concurrent / event driven programming. 3 is no longer a wrapper - it's something much more than that. The advantage of 'roll your own' versus using someone elses system are well rehearsed. GAT
I've never used any of the new features, but they tend to be more for stock trading and I only trade futures. However there was at least one instance where they made a change that wasn't backward compatible. GAT
Sure, with each introduction of new algo order types the wrappers would have to be updated to support those. Some of those order types are used by different people to more or less degrees because they benefit their approach to trading.
Just a word of caution regarding Quantopian: I spent hours per day for a couple months learning python from scratch on quantopian, and now I wish I'd spent that time with C# at quantconnect. They're platform is open to forex, connects with multiple brokers etc. You don't get the perks of pandas and talib but they've taken a nice approach on how the data is fed into the system and have loads of auto-updating indicator functions. Also, they're implementing python if you really want to go that route, it's in Beta right now. I'll be following your thread and hope to help out along the way, it's a lot of work, good luck!
-- do you know what products and what time frames are your going to target in your strategy? -- would you rather run a single "perfect" strategy or run a diversified portfolio of strategies? -- what, in your opinion, in your setup (from asset selection to execution) gives you an advantage over other market players?
Hey, thanks for the tip about quantconnect. As I've been programming for a million years now, I could switch languages very easily. I only see ASTs when I code ;-) The core problem with Quantopian is the focus on stocks. However, I'm going to start with stocks since that is what I already understand. Perhaps with a modicum of success, I will want to level up, so to speak. Or perhaps by starting with stocks, I've already doomed myself?