Fully automated futures trading
- Thread starter globalarbtrader
- Start date
Welcome back. You're not the only one who had these weird messages from Gateway. Myself included. In my case I got an additional message, saying that my Gateway version was too old and no longer supported. However, when I restarted Gateway and agreed to using SSL it ran fine (at least until now). So, for the time being, will I not change the Gateway version. Later Gateway versions have a modified logon/autologoff procedure which IBCalpha can't handle properly, so I would prefer not to use those.
FWIW, IB API team finally called me back and explained that the SSL layer requirement caused widespread havoc and was unexpected so they have been busy fielding calls. They still expect to give 2-3 months notice before deprecating gateway versions and the minimum version they still support is still 972. For those who have not seen Richard King's message you can either check the SSL layer or for headless servers amend the jts.ini file by setting UseSSL=true. After this you should be good to go and IBC still works beautifully!
This is very useful information. Thank you for reporting.
I would appreciate getting more insight in your approach to RV strategies / calendars.
Aside from the technical implementation (fills / risk), I think the 'strategy' perspective would probably give more than enough material for several chapter(s) of book IV, if not enough for book V!
If you don't mind, from a high-level perspective, will you be looking at mean-reversion vs. trend-continuation strategies, as well as pricing vs. other contracts on the curve? (To name a few approaches).
Additionally, where your aproach to trading outrights has been signal generation on individual contracts with a portfolio risk overlay, I think trade management is another factor in calendar / multi-leg trades. I'm specifically referring to the changing characteristics of any combination of a number of multi-legged trades in the same underlying - or closely correlated products - as in calendars turning into (double) flies / condors etc. Will you be looking at this aspect of trade management?
And of course there's reduced-margin / return benefits vs outright positions...
I look forward to getting more involved in this thread on this specific subject!
Hi Rob, as I've already mentioned I'm a big fan! Thank you for all your work!!!
I was testing the Handcrafting method vs what I'm currently using, and I think I've found a bug in candidates matrix method you used before. I know you don't use it anymore.
It's at the end of the function get_weights_using_candidate_method:
# return to original order
#natural_order_weights = [normalised_weights[idx] for idx in list(corr_order)] # I think this where the bug is
#I think this would fix it
natural_order_weights = np.zeros(len(corr_order))
for idx, corr_order_idx in enumerate(corr_order):
natural_order_weights[corr_order_idx] = normalised_weights[idx]
For the matrix
cmatrix = np.array([[1.0, 0.86, 0.56], [0.86, 1., 0.63], [0.56, 0.63, 1.]] )
I was getting [0.258, 0.396, 0.34], while I think the order is wrong, the right one would be
0.34, 0.258, 0.396].
Sorry if this was not the proper channel. Maybe I should have tried to ammend it in pysystemtrade.
Thanks,
Luis
I was testing the Handcrafting method vs what I'm currently using, and I think I've found a bug in candidates matrix method you used before. I know you don't use it anymore.
It's at the end of the function get_weights_using_candidate_method:
# return to original order
#natural_order_weights = [normalised_weights[idx] for idx in list(corr_order)] # I think this where the bug is
#I think this would fix it
natural_order_weights = np.zeros(len(corr_order))
for idx, corr_order_idx in enumerate(corr_order):
natural_order_weights[corr_order_idx] = normalised_weights[idx]
For the matrix
cmatrix = np.array([[1.0, 0.86, 0.56], [0.86, 1., 0.63], [0.56, 0.63, 1.]] )
I was getting [0.258, 0.396, 0.34], while I think the order is wrong, the right one would be
0.34, 0.258, 0.396].
Sorry if this was not the proper channel. Maybe I should have tried to ammend it in pysystemtrade.
Thanks,
Luis
@globalarbtrader I was thinking about a topic and wasn't sure whether you have already addressed it in one of your blog posts. It relates to the futures trading system from your book "Systematic Trading". This system calculates a forecast for an instrument and then translates this to a desired position size. In the book this translation is linear and symmetrical: the forecast can vary between -10 and +10 and the resulting position size varies between maximum short to maximum long. At forecast zero is the position size zero.
Intuitively this makes sense. However, looking at the forecast observations of multiple instruments over the last couple of years I notice that the forecast does not have a midpoint at zero, but has an offset. And the forecast range has a skew: the lower half of observations covers a different range than the upper half.
My question is: would it make sense to adapt the conversion from forecast value to position size from a symmetrical approach to the observed asymmetrical data?
What I would do in this approach is to determine the distribution of observed forecast values and determine the 1% percentile (most negative), 50% (midpoint), and 99% (most positive). And use this scale to translate from actual forecast to desired position size. A few times per year I would review the percentile points and adapt if necessary.
Intuitively this makes sense. However, looking at the forecast observations of multiple instruments over the last couple of years I notice that the forecast does not have a midpoint at zero, but has an offset. And the forecast range has a skew: the lower half of observations covers a different range than the upper half.
My question is: would it make sense to adapt the conversion from forecast value to position size from a symmetrical approach to the observed asymmetrical data?
What I would do in this approach is to determine the distribution of observed forecast values and determine the 1% percentile (most negative), 50% (midpoint), and 99% (most positive). And use this scale to translate from actual forecast to desired position size. A few times per year I would review the percentile points and adapt if necessary.
There are two seperate questions here.
The first is whether you would like your forecasts to always have an expected value of zero. The second is whether you would like to have a nice distribution.
Let's take an example of a slow momentum trend signal. On a market which has generally gone up, this will have a generally positive mean. The question is whether you would want to remove this mean; in other words change the signal so that if the trend was average in size then you'd have no position on; if the trend was above average you'd be long, if the trend was slightly below average you'd be flat.
For me personally, I want to be long in an upwards trend, even if it's only slightly long because the trend is quite weak. So I don't demean my signals. The same applies to carry.
This is because I care about outright performance. However if I was more concerned about adding alpha to a long only benchmark, then demeaning might make sense.
(This is mostly an issue for slower momentum and carry in eg bond markets. If you do the averaging across a typical basket of instruments you're probably going to have more long positions than short
This then brings us to the question of distribution. The question is are we trying to make money, are we mostly concerned with getting positive skew, or are we trying to produce a nice ex-post normal distribution of returns? There is no black or white answer by the way - you can care about all of these things a bit. Personally I'm not that bothered about getting a nice ex-post normal distribution of returns so I wouldn't do the sort of scaling that you propose. I'm pretty sure that such an exercise would also result in some positive skew being taken away (which is bad), and I'm not convinced that it would improve Sharpe Ratio much, if at all.
Although to be clear, I haven't done this exercise; as you know I err on the side of making things as simple as possible but no simpler; this strikes me as a degree of complexity too far so the evidence would have to be pretty compelling for me to take this idea up.
GAT
Thank you for your fast reply and for dissecting the proposal. It helps me to understand how to look at the mean and the distribution (skew) separately. And in what way each of these influences the overall result.
Your remarks about "demean"ing inspires me to look at the bigger picture. In my case do I have a long-only buy&hold ETF portfolio with exposure to the US equity market. Plus the futures trading system which also includes the US equity indexes (e.g. SP500, NASDAQ). The purpose of the futures system is to provide diversification to the ETF portfolio. I'll have to consider whether I want to mean or demean the related futures instruments: would that influence (improve?) the diversification? Or would I make things overly complicated for myself, without getting a real benefit from it? I like to keep things simple, but I also like to have a positive financial benefit.
Your remarks about "demean"ing inspires me to look at the bigger picture. In my case do I have a long-only buy&hold ETF portfolio with exposure to the US equity market. Plus the futures trading system which also includes the US equity indexes (e.g. SP500, NASDAQ). The purpose of the futures system is to provide diversification to the ETF portfolio. I'll have to consider whether I want to mean or demean the related futures instruments: would that influence (improve?) the diversification? Or would I make things overly complicated for myself, without getting a real benefit from it? I like to keep things simple, but I also like to have a positive financial benefit.