 Posted 3/7/2010 09:56:23
|
|
|
|
I would like to confirm whether I have a clear understanding of how stop and limit orders are treated in the RE backtest.
I run on a 3hr system frequency and use hourly fx data. Lets use an example. I short GBP/AUD at 2.0700 at 6pm. I put in a buy stop order above the entry (2.0750) and a take profit limit buy order below the entry (2.0650). At the next system frequency bar 3 hours later the price is 2.0610 and the system shows that it took profit at 2.0650, my take profit limit level.
My question is, how does the system know whether the stop or the limit order level was hit first? I get the same result regardless of whether the high of that 3 hr bar was above or below the stop loss level of 2.0750. How can this be? I mean logically the system has no way to figure the path the price took to get from my entry to the close of the next system frequency bar. In my opinion the logic should at the very least be that I get filled at the price of the closing bar and not at my take profit limit level.
I got the above results from setting the generateTicksFrom Bars to true and even from looking at the hourly bars that make up the 3 hr system frequency bars it was not discernible for the system to deduce whether the stop or take profit level has been hit first.
Another issue is what difference does it make to my specifically described scenario whether setting "generateTicksFromBars" to true or false?
|
|
|
Posted 3/7/2010 13:52:36
|
|
|
|
If both the profit target and the stop loss could have been hit inside the same bar, then there's no way to know which price would have come first. To accurately simulate this you need higher-frequency data. (You can still have your system use hourly bars, but if your data frequency is higher then the fill simulation can be more accurate.)
If you can't use higher-frequency data, you can control whether the high or the low price will be processed first each bar in the system properties (assuming CreateTicksFromBars is true). If you want more control you can probably write your own paper broker plugin (derived from ours). You'd probably want to turn CreateTicksFromBars off in that case, and then override the SimBar and ShouldFill methods.
Thanks,
Daniel
|
|
|
Posted 3/7/2010 21:41:40
|
|
|
|
Daniel thanks for the response.
However, my concern is that this is a bug in RE. If RE does not know whether the stop or limit has been hit first why and how does it chose one of the two? This is not just an issue of accuracy but the backtest will give completely incorrect results. If RE does not or cannot know whether the stop or limit has been hit first then the only logical AND correct way would be to fill at the bar closing price, everything else is making assumptions that are not supported by any available fact. Of course will it be better to use as high frequency data as possible but if those are not available I think it is worth a thought to change the logic how Right Edge fills stops and limit order, given that it cannot be determined which one was reached first. Would you not agree? At least an option to get filled at the close would make a lot of sense if all the above conditions are met. Otherwise of course I agree that stops and limits should get filled at their respective level.
dplaisted (3/7/2010)
If both the profit target and the stop loss could have been hit inside the same bar, then there's no way to know which price would have come first. To accurately simulate this you need higher-frequency data. (You can still have your system use hourly bars, but if your data frequency is higher then the fill simulation can be more accurate.)
If you can't use higher-frequency data, you can control whether the high or the low price will be processed first each bar in the system properties (assuming CreateTicksFromBars is true). If you want more control you can probably write your own paper broker plugin (derived from ours). You'd probably want to turn CreateTicksFromBars off in that case, and then override the SimBar and ShouldFill methods.
Thanks,
Daniel
|
|
|
Posted 3/9/2010 22:23:52
|
|
|
|
I don't think it is more "correct" to choose the bar close price. If the bar close price is between the profit target and the stop loss, then it is a price that would never have actually been used as the fill price to close the position. If the close price is not between those prices, then I think it's actually less likely to be close to the right price. If the close price is the same as the high price, then it is likely that the low price came earlier in the bar than the high price did, so it would likely be more correct to fill the stop loss (assuming a long position).
I can understand wanting to use the close price. If the low price is always processed first then that biases the system towards lower fill prices (and hence shorting). Using the close should reduce that bias.
There are several reasons we don't use the close price as you suggest. The first is that most people with this problem will probably want a different solution than you do, such as randomly choosing whether the profit target or stop loss should be filled, or using the average of the high and low as the fill price, or figuring out whether to process the high or low price first by looking at whether the open is greater than the close. The second is that it's not that RightEdge's architecture is built around processing a stream of discrete prices, in order to avoid accidental lookahead and to mirror real trading. However, this doesn't make it easy to write logic that will take the entire bar into account when deciding how to fill an order. Furthermore, it is complicated by the fact that at the broker level the profit target and stop loss orders aren't linked in any way.
Choosing whether to process the high or low of the bar first at random will do a better job at eliminating the bias, and is a lot easier for us to do, so that is how I expect we will solve this problem.
Thanks,
Daniel
|
|
|
Posted 3/10/2010 20:19:15
|
|
|
|
Thanks for your lengthy explanation of thought process. I am not sure I can agree any more than before. I think when a trader has reached a point where in his back testing process he/she has to rely on a random selection of whether the stop or limit level has been reached first such person should rather start focusing on a work around. Before that the application should in my humble opinion do what it knows not what the bias may be or in what random selection it results. But I acknowledge your opinion and the way you decided to go about this. I could not accept living with such "bias" and went around by using 1 minute intraday data which approximate close enough what happens in real-time, especially given that my stops and limits are far enough apart in order to not be both reached within a minute bar.
dplaisted (3/9/2010)
I don't think it is more "correct" to choose the bar close price. If the bar close price is between the profit target and the stop loss, then it is a price that would never have actually been used as the fill price to close the position. If the close price is not between those prices, then I think it's actually less likely to be close to the right price. If the close price is the same as the high price, then it is likely that the low price came earlier in the bar than the high price did, so it would likely be more correct to fill the stop loss (assuming a long position).
I can understand wanting to use the close price. If the low price is always processed first then that biases the system towards lower fill prices (and hence shorting). Using the close should reduce that bias.
There are several reasons we don't use the close price as you suggest. The first is that most people with this problem will probably want a different solution than you do, such as randomly choosing whether the profit target or stop loss should be filled, or using the average of the high and low as the fill price, or figuring out whether to process the high or low price first by looking at whether the open is greater than the close. The second is that it's not that RightEdge's architecture is built around processing a stream of discrete prices, in order to avoid accidental lookahead and to mirror real trading. However, this doesn't make it easy to write logic that will take the entire bar into account when deciding how to fill an order. Furthermore, it is complicated by the fact that at the broker level the profit target and stop loss orders aren't linked in any way.
Choosing whether to process the high or low of the bar first at random will do a better job at eliminating the bias, and is a lot easier for us to do, so that is how I expect we will solve this problem.
Thanks,
Daniel
|
|
|
|