Fully automated futures trading

Hi @globalarbtrader

Just having a close look at how you calculate positioning and had a few questions.

(1/N)*C*(T/V)*(F/10)

Does C include your unrealised profit or loss (i.e. available margin)?

Is V calculated by multiplying the daily ATR by 14 divided by the current price?

E.g.
Gold price = 1740
Daily ATR = 26.6
V = 26.6 * 14/ 1740 = 0.21

Is this applicable to all timeframes? If not, how does one calculate it so it's timeframe specific?

With F/10, does this mean your strongest forecast is a multiplier of 2 and your average forecast a multiplier of 1? I'm assuming your negative F values are for short positions (i.e. -1 to -20).

If a multiplier greater than 1; doesn't this dilute what you're trying to achieve with 1/N? Why not make the multiplier a maximum of 1 and your average 0.5?

I'm guessing in the context of your complete formula, multiplying by 2 is appropriate. I started with a maximum multiplier of 2 and reverted to 1 because my positions were too large but this was probably due to not having implemented T/V and using my broker's leverage limits as a substitute.
 
Last edited by a moderator:
lovethetrade said:
Hi @globalarbtrader

Just having a close look at how you calculate positioning and had a few questions.

(1/N)*C*(T/V)*(F/10)

Does C include your unrealised profit or loss (i.e. available margin)?

Is V calculated by multiplying the daily ATR by 14 divided by the current price?

E.g.
Gold price = 1740
Daily ATR = 26.6
V = 26.6 * 14/ 1740 = 0.21

Is this applicable to all timeframes? If not, how does one calculate it so it's timeframe specific?

With F/10, does this mean your strongest forecast is a multiplier of 2 and your average forecast a multiplier of 1? I'm assuming your negative F values are for short positions (i.e. -1 to -20).

If a multiplier greater than 1; doesn't this dilute what you're trying to achieve with 1/N? Why not make the multiplier a maximum of 1 and your average 0.5?

I'm guessing in the context of your complete formula, multiplying by 2 is appropriate. I started with a maximum multiplier of 2 and reverted to 1 because my positions were too large but this was probably due to not having implemented T/V and using my broker's leverage limits as a substitute.
More...

First a caveat, this isn't exactly how I calculate positions and includes some simplifications to show the broad principles.

C is my current 'capital at risk'. Roughly speaking it's my current account value so includes any unrealised mark to market profits (see here https://www.elitetrader.com/et/threads/fully-automated-futures-trading.289589/page-179#post-4877015 for what it is more precisely).

I calculate V directly as an annualised standard deviation. The ATR method is an approximation which I don't use, but some people seem to prefer ATR. Not sure what you mean by 'timeframe', the approximation is for taking a daily ATR and converting it to an annualised standard deviation. That would be valid for any trade holding period. It doesn't really matter as long as it's in the same units as the target risk, T. You could if you liked set your target risk in 35 minute ATR units and measure V the same way. But it's much easier to calculate the correct level of target risk T in units of annual standard deviation, eg it follows directly from the Kelly criteria.

No my average forecast is 10, hence F/10 converts that into a number where 1 is the average. My strongest forecast would be 20. The choice of 10 is arbitrary, the system will work just fine if you choose another number. I chose 10 because I feel that numbers like 3.6 are intuitive to humans, and to avoid being sued by my former employers who use 1.

I'm not trying to 'achieve' anything with 1/N, it's just that if you have more markets (N) you need to divide your capital up between them. (again this is an approximation for how I actually allocate capital across markets).

"I'm guessing in the context of your complete formula, multiplying by 2 is appropriate"

I literally have no idea what this means.

GAT
 
globalarbtrader said:
C is my current 'capital at risk'. Roughly speaking it's my current account value so includes any unrealised mark to market profits (see here https://www.elitetrader.com/et/threads/fully-automated-futures-trading.289589/page-179#post-4877015 for what it is more precisely).
More...

Looks like we're on the same page there.

globalarbtrader said:
I calculate V directly as an annualised standard deviation. The ATR method is an approximation which I don't use, but some people seem to prefer ATR. Not sure what you mean by 'timeframe', the approximation is for taking a daily ATR and converting it to an annualised standard deviation. That would be valid for any trade holding period. It doesn't really matter as long as it's in the same units as the target risk, T. You could if you liked set your target risk in 35 minute ATR units and measure V the same way. But it's much easier to calculate the correct level of target risk T in units of annual standard deviation, eg it follows directly from the Kelly criteria.
More...

That didnt really answer my question so I'll try again. Based on the following statement in your blog, is the formula outlined below, correct?

"If you prefer to measure risk using the well known ATR, then as a rule of thumb multiplying the daily ATR by 14 will give you the annual standard deviation."

Is V calculated by multiplying the daily ATR by 14 divided by the current price?

E.g.
Gold price = 1740
Daily ATR = 26.6
V = 26.6 * 14/ 1740 = 0.21

globalarbtrader said:
No my average forecast is 10, hence F/10 converts that into a number where 1 is the average. My strongest forecast would be 20. The choice of 10 is arbitrary, the system will work just fine if you choose another number. I chose 10 because I feel that numbers like 3.6 are intuitive to humans, and to avoid being sued by my former employers who use 1.
More...

I think that's pretty much what I was saying so in agreement there also.

globalarbtrader said:
I'm not trying to 'achieve' anything with 1/N, it's just that if you have more markets (N) you need to divide your capital up between them. (again this is an approximation for how I actually allocate capital across markets).
More...

If you've implemented it then it has to have an objective attached to it. Not sure what the confusion is there. Looks like we're in agreement here also.
 
lovethetrade said:
Looks like we're on the same page there.



That didnt really answer my question so I'll try again. Based on the following statement in your blog, is the formula outlined below, correct?

"If you prefer to measure risk using the well known ATR, then as a rule of thumb multiplying the daily ATR by 14 will give you the annual standard deviation."

Is V calculated by multiplying the daily ATR by 14 divided by the current price?

E.g.
Gold price = 1740
Daily ATR = 26.6
V = 26.6 * 14/ 1740 = 0.21
More...

The formula is correct. But it is an approximation/ rule of thumb (it's partly based on theory, partly on empirical evidence), not a canonical equation. Like I said, I don't use it personally. Instead I calculate 'V' directly as a standard deviation (of daily returns, which I then annualise).

GAT
 
Hi GAT,

Just to avoid any confusion.

My implementation of this formula was almost identical to yours (excluding T/V) before actually seeing your blog. My objective with 1/N is to allow the portfolio to be diversified as intended and to give "equal opportunity" to all instruments/assets within the portfolio. By using a multiplier of 2, I determined that this might over-allocate towards some instruments based on a first-in first-served basis so that was part of the reason why I reverted to a maximum multiplier of 1. That's why I suggested it might dilute what you're trying to achieve with 1/N.

Over and out.
 
Last edited by a moderator:
My trading system, which has been running since April 2014, has just fallen over: permanently. I was forced to upgrade my TWS gateway, and there was a non backwardly compatible change which meant https://pypi.org/project/swigibpy/ mostly stopped working. The original author is no longer supporting this pretty ancient project now. I could try and fix it, but the more sensible thing is to finally start using pysystemtrade for live trading.

I have a few days of work before I can use it for trading manually (during which time I won't be trading at all), and then a bit more time before I've replicated all the functionality of the original codebase (primarily fully automated trading). I have about 6 weeks to do this now, since I want to have something running over the summer.

So I've cerimonusly typed 'crontab -r' into the current trading machine and begin copying over all 55gb of historic data, some of which I will use to back populate the new databases (I'm not sure which yet, so best to keep them all).

(This reminds me of when AHL retired the first trading system I developed for them. That time I had the honour of doing the final trade)

I knew this day was coming, and it was one of the reasons I had started on pysystemtrade to begin with. In a way this is a good thing, since it's forced me to focus and avoid getting bogged down in anything that isn't going to get the thing running ASAP.

It's also made me slightly nervous in that I've now got a reliance on another third party project in the new system, https://github.com/erdewit/ib_insync, albeit one which seems more well supported and not just a hobby project. I did initially go down the route of building my own interface to IB API, but I was having trouble getting it to work reliably so this was a quick and easy solution (and I'm glad I did it, or I wouldn't be this close to ). At least this time round the abstractions are much cleaner and I could more easily, if I had to, switch over to another API layer.

GAT
 
globalarbtrader said:
My trading system, which has been running since April 2014, has just fallen over: permanently. I was forced to upgrade my TWS gateway, and there was a non backwardly compatible change which meant https://pypi.org/project/swigibpy/ mostly stopped working. The original author is no longer supporting this pretty ancient project now. I could try and fix it, but the more sensible thing is to finally start using pysystemtrade for live trading.

I have a few days of work before I can use it for trading manually (during which time I won't be trading at all), and then a bit more time before I've replicated all the functionality of the original codebase (primarily fully automated trading). I have about 6 weeks to do this now, since I want to have something running over the summer.

So I've cerimonusly typed 'crontab -r' into the current trading machine and begin copying over all 55gb of historic data, some of which I will use to back populate the new databases (I'm not sure which yet, so best to keep them all).

(This reminds me of when AHL retired the first trading system I developed for them. That time I had the honour of doing the final trade)

I knew this day was coming, and it was one of the reasons I had started on pysystemtrade to begin with. In a way this is a good thing, since it's forced me to focus and avoid getting bogged down in anything that isn't going to get the thing running ASAP.

It's also made me slightly nervous in that I've now got a reliance on another third party project in the new system, https://github.com/erdewit/ib_insync, albeit one which seems more well supported and not just a hobby project. I did initially go down the route of building my own interface to IB API, but I was having trouble getting it to work reliably so this was a quick and easy solution (and I'm glad I did it, or I wouldn't be this close to ). At least this time round the abstractions are much cleaner and I could more easily, if I had to, switch over to another API layer.

GAT
More...
Ouch. Although if a trend following system is going to fall over, it might as well do it when there are no strong trends around. It must be daunting to migrate a critical layer of existing code to fit a new API, but from personal experience you could do far worse than Ewald's project. You might of course need to swat up a little (not a lot) on asyncio. Best of luck with the refactor!
 
globalarbtrader said:
My trading system, which has been running since April 2014, has just fallen over: permanently. I was forced to upgrade my TWS gateway, and there was a non backwardly compatible change which meant https://pypi.org/project/swigibpy/ mostly stopped working. The original author is no longer supporting this pretty ancient project now. I could try and fix it, but the more sensible thing is to finally start using pysystemtrade for live trading.

I have a few days of work before I can use it for trading manually (during which time I won't be trading at all), and then a bit more time before I've replicated all the functionality of the original codebase (primarily fully automated trading). I have about 6 weeks to do this now, since I want to have something running over the summer.

So I've cerimonusly typed 'crontab -r' into the current trading machine and begin copying over all 55gb of historic data, some of which I will use to back populate the new databases (I'm not sure which yet, so best to keep them all).

(This reminds me of when AHL retired the first trading system I developed for them. That time I had the honour of doing the final trade)

I knew this day was coming, and it was one of the reasons I had started on pysystemtrade to begin with. In a way this is a good thing, since it's forced me to focus and avoid getting bogged down in anything that isn't going to get the thing running ASAP.

It's also made me slightly nervous in that I've now got a reliance on another third party project in the new system, https://github.com/erdewit/ib_insync, albeit one which seems more well supported and not just a hobby project. I did initially go down the route of building my own interface to IB API, but I was having trouble getting it to work reliably so this was a quick and easy solution (and I'm glad I did it, or I wouldn't be this close to ). At least this time round the abstractions are much cleaner and I could more easily, if I had to, switch over to another API layer.

GAT
More...
Oh, that's some unplanned work.. Yeah, every external dependency is a cost, even if the library is free :) , but sometimes there's just no other way.. Good luck, let us know how it goes..
 
Did my first manual trades today. Basically I have got the code to put where it can publish desired orders, and then I have to manually type in fills which then get propagated. Painful, but there are a few advantages to this approach (apart from the fact that it was the fastest way to replace my current system):

  • I've had to build some cool CLI tools for managing this process which are much nicer than the ones in my old code
  • manual trading is automatically supported for people who want to use a non IB solution
  • If something happens with IB I can switch to another broker and manually trade until I get the API code
  • If the intermediary IB API layer I am using breaks again, then I can fall back to manual trading until I find a replacement or it's fixed
  • it's a lot safer to test everything is working upstream of the broker code

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