Fully automated futures trading

wopr said:
I'm debugging something with my DO implementation (gist of the issue is, in my backtesting, performance of the DO drops significanly with lowering the capital, eg. from a 1.14 SR for a Jumbo portfolio to 0.91 SR for DO with 800K, for the same forecasts), I think I narrowed it down to correlation and covariance calculation.

Rob, I wanted to ask, what's the difference between `instrument_correlation_estimate` key in the config (https://github.com/robcarver17/pysy...d514549e2cf/sysdata/config/defaults.yaml#L226) and `instrument_returns_correlation` 50 lines below, besides obviously the parameters? I see that the latter one is used in reports, so the correlations on the risk report are not the same as the ones used in the DO run (besides obviously not being shrunk).
If I read the code correctly, I think the former is used in the DO run, with `floor_at_zero` set to false. Also, since the lookbacks are so short (25/75 weeks), the roll years parameter is irrelevant, is that right?

Thank you in advance!
More...

Former is for the correlation of substrategy returns, latter is the correlation of the underlying instrument returns. So the latter is more appropriate for a risk report, and DO calculations. The former you'd use for IDM estimation and instrument weight estimation.

Rob
 
I've been playing with DO implementation, and stumbled upon what could be a slight improvement so wanted to share.

I've been trading Rob's implementation of DO for about 2 years now, and I've been noticing that I would sometimes have a position on in an instrument that has optimal unrounded, eg. 0.17, and have nothing on in something with optimal unrounded 1.7. Digging into this, I think it is because since the algo is greedy, if the 0.17 one has a big notional, it will take that as that will reduce the tracking error the most in that step. Then it never gets to the 1.7 one, as the notional is much smaller.

I've made the following modification: instead of starting from 0 weights for all instruments as the starting point for the DO, start from the
Code: 
round(unrounded_optimal_position)
. I then increase/decrease the weight towards optimal unrounded weight in the DO iterations.
That does indeed reduce the occurrences I've mentioned above. It also prevents the situation of forecast flipping - when forecast is around 0, original implementation has to switch position (I believe buffering deals with that to an extent). The reason it prevents that situation is that if the optimal unrounded is [-0.49, 0.49], we'll start from 0 anyways, so variations around 0 forecast/optimal unrounded are not as impactful.

Running a backtest on 104 instruments, about 20 years of data, I get lower average tracking error, 3.81% vs 4.65% with the original method.
Here's a chart with difference over time.
upload_2024-4-8_17-50-54.png


The downside is that on average, you hold a lot more positions, for the same backtest, average positions held is 22 for Rob's method vs 29 for my modified version.

Risk is almost exactly the same, slightly smaller for my method.

Has anybody played with something similar? Would be interested to see if anyone could replicate these results.
 
globalarbtrader said:
I've come to the same conclusion myself and at some point was going publish a mea culpa blog post, but it's hard to find time to do something which won't add value.

My own tentative fiddling about suggests that a version where you wait until the MR divergence is higher is profitable (discovered by accident when noticing a big difference between rounded and unrounded results for small capital), which is the more standard way of running such a strategy.

Apologies

Rob
More...
Hello globalarbtrader,

How much upfront capital is needed to trade your portfolio of algos?

Thank you,
 
wopr said:
I've been playing with DO implementation, and stumbled upon what could be a slight improvement so wanted to share.

I've been trading Rob's implementation of DO for about 2 years now, and I've been noticing that I would sometimes have a position on in an instrument that has optimal unrounded, eg. 0.17, and have nothing on in something with optimal unrounded 1.7. Digging into this, I think it is because since the algo is greedy, if the 0.17 one has a big notional, it will take that as that will reduce the tracking error the most in that step. Then it never gets to the 1.7 one, as the notional is much smaller.

I've made the following modification: instead of starting from 0 weights for all instruments as the starting point for the DO, start from the
Code: 
round(unrounded_optimal_position)
. I then increase/decrease the weight towards optimal unrounded weight in the DO iterations.
That does indeed reduce the occurrences I've mentioned above. It also prevents the situation of forecast flipping - when forecast is around 0, original implementation has to switch position (I believe buffering deals with that to an extent). The reason it prevents that situation is that if the optimal unrounded is [-0.49, 0.49], we'll start from 0 anyways, so variations around 0 forecast/optimal unrounded are not as impactful.

Running a backtest on 104 instruments, about 20 years of data, I get lower average tracking error, 3.81% vs 4.65% with the original method.
Here's a chart with difference over time.
View attachment 337794

The downside is that on average, you hold a lot more positions, for the same backtest, average positions held is 22 for Rob's method vs 29 for my modified version.

Risk is almost exactly the same, slightly smaller for my method.

Has anybody played with something similar? Would be interested to see if anyone could replicate these results.
More...

Now that looks like a very nice idea... I may well steal it.

Rob
 
Hi wopr,

I implemented the DO using Mixed Integer Programming and always have positions in much more instruments. I posted about it months ago. Today I have positions in 50 instruments for ~600k capital. Probably it is more relevant if you trade lots of micro contracts like I do.

I uploaded my first implementation in Python and C# here, but I need to update it with the version I'm running in production. This does not have any buffering. But in case you want to have a look:

https://github.com/golforado/tracking-portfolio

Thanks,
Luis
 
cholo said:
Hi wopr,

I implemented the DO using Mixed Integer Programming and always have positions in much more instruments. I posted about it months ago. Today I have positions in 50 instruments for ~600k capital. Probably it is more relevant if you trade lots of micro contracts like I do.

I uploaded my first implementation in Python and C# here, but I need to update it with the version I'm running in production. This does not have any buffering. But in case you want to have a look:

https://github.com/golforado/tracking-portfolio

Thanks,
Luis
More...

Hi Luis, thanks for posting!
I saw that and actually spent a good week trying to make that work, but I just couldn't figure it out. You defined the problem slightly differently and I couldn't figure out how to replicate it, I think I got confused by the target risk multiplier.
Added to that that I couldn't really find a solver that would work (I still can't figure out how to download CPLEX :D) and was reasonably priced, I gave up. Would be very interested in the refreshed version with buffering though.

Thanks for mentioning that you also have more positions on, makes me think that my approach here is in the right direction. I'm running a bit more capital, and 45 positions on at the moment.
 
wopr said:
Hi Luis, thanks for posting!
I saw that and actually spent a good week trying to make that work, but I just couldn't figure it out. You defined the problem slightly differently and I couldn't figure out how to replicate it, I think I got confused by the target risk multiplier.
Added to that that I couldn't really find a solver that would work (I still can't figure out how to download CPLEX :D) and was reasonably priced, I gave up. Would be very interested in the refreshed version with buffering though.

Thanks for mentioning that you also have more positions on, makes me think that my approach here is in the right direction. I'm running a bit more capital, and 45 positions on at the moment.
More...

There's a CPLEX Optimization Studio Free Edition, even though it has limitations (1000 variables/ contraints)
 
Everyone wants to be "fully" automated until the exchanges change things on you.

For anyone trading BAX futures, I got this from IB:

BAX to CORRA futures Migration
Dear Trader,

Since you either have positions or have previously traded in Montreal Exchange listed BAX contracts, we want to make you aware that on 04/26/24, trading on all BAX contracts (except June 2024 expiration) would cease. All BAX contracts expiring after June 2024 will be converted to CORRA equivalents.

The conversion will take place on 04/27/24; we expect that customer accounts would reflected updated CORRA positions by the start of trading on 04/29/24. Note also that June 2024 BAX futures will remain listed and trade until the standard expiration date.

The Montreal Exchange FAQ – Transitioning to CORRA documentation can be found here.​

Personally, I just have to add the CORRA contracts to my system and it won't be confused by the fact that my BAX contract disappeared and a corresponding CORRA contract appears (assuming I have an open position in BAX, which I currently do). Still, I hate anything that would possibly break my system if I had been on vacation or not paying attention.
 
newbunch said:
Everyone wants to be "fully" automated until the exchanges change things on you.

For anyone trading BAX futures, I got this from IB:

BAX to CORRA futures Migration
Dear Trader,

Since you either have positions or have previously traded in Montreal Exchange listed BAX contracts, we want to make you aware that on 04/26/24, trading on all BAX contracts (except June 2024 expiration) would cease. All BAX contracts expiring after June 2024 will be converted to CORRA equivalents.

The conversion will take place on 04/27/24; we expect that customer accounts would reflected updated CORRA positions by the start of trading on 04/29/24. Note also that June 2024 BAX futures will remain listed and trade until the standard expiration date.

The Montreal Exchange FAQ – Transitioning to CORRA documentation can be found here.​

Personally, I just have to add the CORRA contracts to my system and it won't be confused by the fact that my BAX contract disappeared and a corresponding CORRA contract appears (assuming I have an open position in BAX, which I currently do). Still, I hate anything that would possibly break my system if I had been on vacation or not paying attention.
More...

I'm also trading this one, but never had an actual position in it, probably that's why IB didn't send me this email, thanks for sharing!
 
You must log in or register to reply here.
Back
Top