Futures carry is not my space and I might be missing something. What is the rationale for choosing the most liquid contract given that your size is a negligible fraction of liquidity across the curve? Or do you assume that you will get the best execution quality this way?
I meant don't trade the 1st or the 2nd contract (because the jump in volume is so high) - I wasn't talking about trading the spread (which I wouldn't do eithier). GAT
That's not what I was after, I was wondering simply why you have such an emphasis on liquidity profile for contract selection considering your own size? Ps. Sorry, maybe I was not clear - it was more of a general question across all your futures. I am sure you explained it before, too.
That’s very helpful, thanks GAT. I know you have been fairly consistent in your message to avoid the front end of GE, so this just further adds to the list of reasons. I am currently working on my generic stitching algo and hopefully once I have mastered the vagaries and liquidities of the different delivery schedules (a lot less straightforward than I envisaged - some don’t even have consistent calendars), hopefully I should be able to pull up such useful vol comparisons as well. On a related subject, I have read your stuff on data storage and I was wondering if you still keep your price data on csv files, I find them easiest to munge data manually when the code isn’t sufficient, or have you migrated the live system to something faster like HDF or even sqlite? For a slow system would it even matter? If your database choices are proprietary these days, I would of course completely understand.
@globalarbtrader and @Elder thank you for your conversation about GE. Until now was I using the contract which expires in December 2017. However, I noticed today that the December 2018 has recently a larger daily trading volume. And its price volatility seems a bit larger. Time for me to move over. This is one of those contracts that you don't have to bother about rolling so often (in my view, that is). Thus having the risk of overlooking it.
@Elder, checkout Arctic https://github.com/manahl/arctic i'm using it in my live system as the core database for ticks, end of day data (source Quandl) and even for intermediate model results during research (in a separate namespace / db). Arctic is a layer at the client end of Mongodb which compresses numpy arrays and has time slicing addressing built-in. It is blazing fast even over the wire when Mongo is hosted in the cloud - wonderful! And free
Thanks for the tip, I shall definitely check it out. Question: How much effort was it on your part to get up to speed with it? I generally find incorporating libraries things that aren't 'batteries' to Python a major undertaking, but perhaps that's just me being lazy.
the API is extremely simple and analogous to Python dictionaries. It's a simple key value store where the values can be Python objects (serialised automatically by Arctic) or pd.Dataframes or np.array all stored as ndarry natively and so can be sliced and diced to save streaming back the whole object to the client - nice!