I want to derive a meaningful value to plug back into TB from my actual trading data. TB defines the slippage as the percentage of the OrderFill from the OrderPrice to the DaysHigh:
Slippage % = (ActualFill - OrderPrice) / (High - OrderPrice) * 100
Which is all when and good. I can then calculate my slippage on each real life trade, and take the average. However, in situations where I get a good fill (e.g better than the OrderPrice -- "Negative Slippage") and the distance between the High and OrderPrice is very low, the above calculation can give me extremely distorting values for slippage - the slippage may be -200%, for example. This results in an average slippage which is overly optimistic.
There are some obvious solutions, but I'm not sure....
1) I could take a very conservative estimate whereby I only take an average of those values where slippage > 0.
2) I could take a fairly conservative estimate whereby when slippage is less than zero, I change the value to zero. I then take an average of all values.
3) I could calculate the slippage for those with negative slippage as the distance to the days low (e.g, so that the maximum negative slippage is also -100%). This would seem to produce the most realistic figure.
What do people do here?
How to calculate actual slippage from real life results?
-
- Roundtable Fellow
- Posts: 86
- Joined: Sun Jul 05, 2009 11:10 am
Do you have access to the Blox Marketplace? If so, this free download may stimulate your thinking: (LINK)
This example block loads up a custom slippage file so that each market can use a different slippage amount. The fill prices are then computed using this custom value.
-
- Roundtable Fellow
- Posts: 86
- Joined: Sun Jul 05, 2009 11:10 am
Thanks sluggo, I did see that, it does seem useful. Fwiw I'm trading stocks, so sometimes I will only trade an instrument once, hence I haven't looked closely until now.
Nonetheless, I guess in theory using ATR/volatility based slippage would overcome my above calculation problem. However, at this point in time, I am backtesting using TB, and real-life trading using custom software. It would be some work to get the ATR for the instruments I have traded, and then plug this back into my spreadsheet for ATR based slippage results.
Thus, for the time being, I'm going to have to go with something like number (3) above for simplicity, unless anyone has any thoughts? What do others do?
Nonetheless, I guess in theory using ATR/volatility based slippage would overcome my above calculation problem. However, at this point in time, I am backtesting using TB, and real-life trading using custom software. It would be some work to get the ATR for the instruments I have traded, and then plug this back into my spreadsheet for ATR based slippage results.
Thus, for the time being, I'm going to have to go with something like number (3) above for simplicity, unless anyone has any thoughts? What do others do?
One of the ways the Marketplace Block may stimulate your thinking is this: it may nudge you towards realizing
The list of your ideas might include
- Eureka, I am not forced to use the slippage calculation formula presupplied in Blox! I can write my own code to calculate and charge slippage however I wish!
The list of your ideas might include
- XYZ percent of the (High - Low) range of the entry bar
- XYZ percent of the True Range of the entry bar
- XYZ percent of the N-bar ATR
- XYZ percent of the N-bar range: HH(N) - LL(N)
- XYZ percent of the N-bar standard deviation of closes
- Randomly chosen sample from a file of your actual slippages on your actual trades
- Randomly chosen sample from a probability density function of your own choosing
- The average of calculations 1-5 above
- The second-biggest value from calculations 1-5 above
- Whichever is bigger: (2 x instrument.minimumTick), or calculation 3 above
- Whichever is smaller: $100, or the average of calculations 2 and 4 above
-
- Roundtable Fellow
- Posts: 86
- Joined: Sun Jul 05, 2009 11:10 am
lol @ sarcasm, fair enuff ..... BUT I WANT WANT WANT quick easy fixes/hacks..... writing a custom slippage block is sooo far down the to-do-list that it isn't even funny.
OK I'm going to try and think for myself here, so please be patient with me.....
I should imagine that 1-5 above are going to give somewhat comparable results. However, ATR/volatilty could be problematic under my current system (atypical market conditions). Moreover, given that I have actually been keeping data for (1), I would like to use something along those lines. However, I'm struggling to think of a simple/elegant way to take this data from real-life, get a value e.g. 20% slippage, and plug it into TB (with either the default, or with a custom block).
With your no.1 - slippage as a % of distance from High-Low: This would work fine for record keeping. However, when backtesting with TB, it could give some strange results where the entry point is very close to e.g. the high, but the low is a long distance away. Essentially the mirror of my original problem.... which brings me full circle. So maybe I should run with my original suggestion number 3 for now.... I can't think of a better simple solution for now.
OK I'm going to try and think for myself here, so please be patient with me.....
I should imagine that 1-5 above are going to give somewhat comparable results. However, ATR/volatilty could be problematic under my current system (atypical market conditions). Moreover, given that I have actually been keeping data for (1), I would like to use something along those lines. However, I'm struggling to think of a simple/elegant way to take this data from real-life, get a value e.g. 20% slippage, and plug it into TB (with either the default, or with a custom block).
With your no.1 - slippage as a % of distance from High-Low: This would work fine for record keeping. However, when backtesting with TB, it could give some strange results where the entry point is very close to e.g. the high, but the low is a long distance away. Essentially the mirror of my original problem.... which brings me full circle. So maybe I should run with my original suggestion number 3 for now.... I can't think of a better simple solution for now.
Just imagine that history woulda been different if your buy order was present.
The historical "high" price in your historical data set, came from an alternate universe that did not include your buy order. In another, different, alternate universe which does include your buy order, your bidding influences other market participants. Just imagine the result being a higher "high", which enables your buy order to be filled at (your_orderprice + your_slippage) and still remain below the (now higher) high.
Or, imagine that history woulda been half-different. Calculate price1 = (your_orderprice + your_slippage). Calculate price2 = MIN(price1, Historical_High).
Fill half your order at price1 and the other half at price2. When in doubt, do half. (reference)
The historical "high" price in your historical data set, came from an alternate universe that did not include your buy order. In another, different, alternate universe which does include your buy order, your bidding influences other market participants. Just imagine the result being a higher "high", which enables your buy order to be filled at (your_orderprice + your_slippage) and still remain below the (now higher) high.
Or, imagine that history woulda been half-different. Calculate price1 = (your_orderprice + your_slippage). Calculate price2 = MIN(price1, Historical_High).
Fill half your order at price1 and the other half at price2. When in doubt, do half. (reference)
-
- Roundtable Fellow
- Posts: 86
- Joined: Sun Jul 05, 2009 11:10 am
lets not forget the butterfly effect!
your 1 lot triggers a snowball of orders that , while not giving any slippage to that order itself, triggers a black swan blow out of a 25ATR multiple consecutive limit days price spike, which results in your other 3 strategies/units all getting filled at obscene prices
your 1 lot triggers a snowball of orders that , while not giving any slippage to that order itself, triggers a black swan blow out of a 25ATR multiple consecutive limit days price spike, which results in your other 3 strategies/units all getting filled at obscene prices
-
- Roundtable Fellow
- Posts: 86
- Joined: Sun Jul 05, 2009 11:10 am