Fully automated futures trading

globalarbtrader said:
Er no I've explained it wrong. What I'm saying let's suppose I had to trade Gilts. I can trade them using end of day data to calculate my position (from something like quandl.com although I haven't checked to see if they have Gilts specifically), then submit a market order during the following day. That will cost me on average £5 in slippage per contract (mid to bid/ask assuming a 1 tick = £10 spread). I'd guesstimate that I'd probably trade around 50 lots a year of Gilts, costing me £250.

Alternatively I could pay for data, in which case I'd be able to use a smart execution algo like I currently do for all the markets I trade. I know from experience that will cut my slippage by around 80% to something like £1 a lot. So I'd save 50 lots x £4 = £200. If I have to pay more than £200 for the data, then this isn't worth doing.

GAT
More...

I see, that's an interesting way to think about it.

Have you done any testing on spot FX trading? I have seen papers with very impressive results using only carry indicators with a basket of currencies.
 
tradrjoe said:
I see, that's an interesting way to think about it.

Have you done any testing on spot FX trading? I have seen papers with very impressive results using only carry indicators with a basket of currencies.
More...

Yes.. but I wonder if those papers include the interest spread you have to pay as a retail trader when borrowing / lending foreign currency. In any case I'd rather trade the forwards of the non IMM futures currencies, but that's very much an institutional game.

GAT
 
Mac777 said:
GAT, first of all thanks for a really interesting book which I owe you an Amazon review for.

Assessing my market list is on my "to do" list since I'm thinking about carving out different markets for some new strategies at some point. At this point I'll do the analysis properly.

On a philosophical level the quote above struck me. Is there an element of this being the constant urge to tinker that accuse the big players of? Statistically you presumably don't expect to generate anything to suggest that the results are sufficiently better than your current system to abandon that, do you? So is it ultimately just a question of further diversification? Or is there more to it than that?
More...

Thanks for the kind words.

To explain my thinking in more detail: I have some ideas for other kinds of trading systems, but which will use futures markets. These are relatively fast systems which I'd need a seperate "engine" to run. However to make my life easier I wouldn't want to run both my current system and a faster system on the same market at once. So I'd need to select certain instruments for use with the new system.

This would leave "holes" and is an opportunity for a proper review in light of recent research I've done on diversification. My current list is a bit unbalanced anyway (perhaps slightly too many bond markets for example). I never rigorously sat down originally and did the exercise of adding the most diversifying markets first. I will have to carve out some risk capital for the new system, which will leave the existing one a little short. I need to think about the diversification vs granularity problem I posed in my blog post and see if the number of markets is about right.

Were it not for this I'd probably leave my market list alone. I certainly wouldn't expect any improvement in performance from this exercise; however the new systems should add something so overall it's worth doing.

GAT
 
AvantGarde said:
Hi GAT, I have included your breakout rule with several parameters ranging from 20 to 320 in pysystemtrade as well as ewmac (parameters from 2 to 256) and carry, and applied the optimization process to these.

I have used the same sample set of instruments as you include with pysystemtrade. For curiosity, I grouped all breakout and ewmac rules together and mapped out their equity curves to compare with what you produced in the post above.

I am concerned that my breakout system and ewmac system are very highly correlated (see attached graph below), where as yours do not seem to be correlated. Have you adjusted any other parameters around your breakout strategy / do you have any insight as to why my ewmac and breakout curves move very close to one another?

Thanks!

View attachment 164060
More...

Hi Rob,

I have tried numerous variations to get around the high correlation between the EWMAC and breakout systems, but to no avail. Do you have any insight you can provide?

RULES.png

I basically use:
from systems.provided.futures_chapter15.basesystem import *
with my config.

I don't seem to be able to upload my YAML config, but the optimisation parameters are as follows:

'''
#
use_forecast_scale_estimates: True
#
forecast_scalar_estimate:
pool_instruments: True
#
# forecast combination
#
use_forecast_weight_estimates: True
#
forecast_weight_estimate:
method: bootstrap
frequency: W
pool_instruments: True
date_method: expanding
monte_runs: 100
cleaning: True
bootstrap_length: 50
ewma_span: 125
#
rule_variations: ['ewmac4_16', 'ewmac8_32', 'ewmac16_64','ewmac32_128', 'ewmac64_256', 'carry', 'breakout20', 'breakout40', 'breakout80', 'breakout160', 'breakout320']
#
#
forecast_correlation_estimate:
pool_instruments: True
#
use_instrument_weight_estimates: True
#
instrument_weight_estimate:
method: bootstrap
frequency: W
pool_instruments: True
date_method: expanding
monte_runs: 100
cleaning: True
bootstrap_length: 50
ewma_span: 125
'''
 
AvantGarde said:
Hi Rob,

I have tried numerous variations to get around the high correlation between the EWMAC and breakout systems, but to no avail. Do you have any insight you can provide?

View attachment 164257

I basically use:
from systems.provided.futures_chapter15.basesystem import *
with my config.

I don't seem to be able to upload my YAML config, but the optimisation parameters are as follows:

'''
#
use_forecast_scale_estimates: True
#
forecast_scalar_estimate:
pool_instruments: True
#
# forecast combination
#
use_forecast_weight_estimates: True
#
forecast_weight_estimate:
method: bootstrap
frequency: W
pool_instruments: True
date_method: expanding
monte_runs: 100
cleaning: True
bootstrap_length: 50
ewma_span: 125
#
rule_variations: ['ewmac4_16', 'ewmac8_32', 'ewmac16_64','ewmac32_128', 'ewmac64_256', 'carry', 'breakout20', 'breakout40', 'breakout80', 'breakout160', 'breakout320']
#
#
forecast_correlation_estimate:
pool_instruments: True
#
use_instrument_weight_estimates: True
#
instrument_weight_estimate:
method: bootstrap
frequency: W
pool_instruments: True
date_method: expanding
monte_runs: 100
cleaning: True
bootstrap_length: 50
ewma_span: 125
'''
More...

I'm in the middle of a big recoding exercise and when I've finished I will have a look at this. Did you see if the correlations of individual forecasts came out at similar levels to those in my latest blog post?

GAT
 
isotope1 said:
Hi GAT,

A quick question, I'm looking at https://github.com/robcarver17/pysy...7345f060/sysdata/legacycsv/CORN_carrydata.csv

I'm trying to rebuild this data from https://www.quandl.com/data/CME, but its proving to be a messy implementation, with custom stuff for each instrument.

How did you source/preprocess the data before sticking it into pysystemtrade?
More...

Yes it's messy. You need a table of contract offsets (carry vs price). First I pulled in all the relevant contracts individual prices. I generated a .csv file of roll dates, assuming the roll was done a constant distance before expiry (which varies depending on the contract). I then have other code that checked there was prices for both contracts, old and new, and shifted the roll date around until it found a suitable roll date. Some manual hacking of the .csv file dates was still needed.

This is something I'll be including, with examples, in the next iteration or the one after of the code.

GAT
 
One more question, how come you traded stuff a year out as opposed to from the front? Is that to reduce the number of rolls?

Thanks
 
You must log in or register to reply here.
Back
Top