 Posted 12/27/2009 21:51:59
|
|
|
|
I would like to filter limit orders for the following bar in daily backtesting (it is more cost effective to find daily data then intraday data). That is, to test my system for robustness, I would like to Not execute a limit order that is within X cents (or percent) of the following bar or if the following bar has limited liquidity. This will ensure that unrealistic orders are not filled during backtesting and will reflect worst case fill conditions. An example of the system producing an incorrect fill (unable to ascertain via daily data) is that if an order is submitted for 1000 shares at a limit price that happens to equal the following bars daily low but in reality only 100 shares were traded at the low. In backtesting this could obviously produce optimistic results.
Is there a way to implement this as I understand there is no lookahead features (except for the BarClosing event) or is there a way to post cancel the order so that it does not show up in the backtesting results?
Thanks, Duane
|
|
|
Posted 12/28/2009 08:07:52
|
|
|
|
I have not tried this, but one option is to override NewTick. By default, RightEdge breaks the bar data into ticks (4 ticks for OHLC).
public override void NewTick(BarData partialBar, TickData tick)
{
// evaluate price concerns here
}
I'm just not certain that the request to cancel would be processed fast enough.
dwebber (12/27/2009)
I would like to filter limit orders for the following bar in daily backtesting (it is more cost effective to find daily data then intraday data). That is, to test my system for robustness, I would like to Not execute a limit order that is within X cents (or percent) of the following bar or if the following bar has limited liquidity. This will ensure that unrealistic orders are not filled during backtesting and will reflect worst case fill conditions. An example of the system producing an incorrect fill (unable to ascertain via daily data) is that if an order is submitted for 1000 shares at a limit price that happens to equal the following bars daily low but in reality only 100 shares were traded at the low. In backtesting this could obviously produce optimistic results.
Is there a way to implement this as I understand there is no lookahead features (except for the BarClosing event) or is there a way to post cancel the order so that it does not show up in the backtesting results?
Thanks, Duane
|
|
|
Posted 12/28/2009 11:57:30
|
|
|
|
You can derive your own paper broker class from our built-in PaperTrader, and override the ShouldFill method. You won't have access to the whole bar at that point, but you can also override the SimTick method to track what ticks are coming in, and should be able to figure out which ticks are high or low ticks.
Thanks,
Daniel
|
|
|
Posted 12/28/2009 13:45:53
|
|
|
|
If possible, I would like to put in a request for the ability to filter trades on the next bar per my original post. In general, I agree that Not allowing lookahead in backtesting is a good idea. I have spent many hours debugging code in other packages only to realize that I was accidentally peeking into the future. However, looking ahead is valuable for the above filtering idea because intraday data is not widely available, and inexpensive, that extends back multiple years (10+ years). Filtering trades via the above allows for the use of daily data and greatly expedites the backtesting time required. This is especially important in limit based systems where small data deviancies from actual versus reported, and/or liquidity issues, can greatly alter the system results.
Please let me know your thoughts.
Thanks, Duane
|
|
|
Posted 12/29/2009 07:25:53
|
|
|
|
|
|
|
Posted 12/30/2009 14:40:51
|
|
|
|
As I mentioned, I think this should be done in the paper broker, and with a little work I think it is possible to do today by deriving from the existing paper broker.
Daniel
|
|
|
Posted 12/30/2009 17:37:11
|
|
|
|
Daniel, thanks for the suggestion on modifying the paper broker. Would it be possible for you to provide an implementation of a paper broker that supports this functionality?
On top of developing strategies, indicators, and my normal work schedule I would prefer to stay away from the details of a paper broker although it is very good to know that it can be extended if needed. The extensibility of your platform is a very attracted feature.
Btw: I've seen discussions about lookahead functionality by other traders in other forums such as WL, so I believe that it may be a worthwhile pursuit.
Thanks for your support.
Duane
|
|
|
Posted 1/1/2010 15:32:07
|
|
|
|
Daniel, after looking at your SlippagePagerTrader implementation, I believe the coding easier than I thought. I'm more impressed with RE's extensibility every day. Please let me know if the following modifications for the ShouldFill method look correct for a limit buy:
const double limitFilterAmount = 0.02;
if (order.OrderType == OrderType.Limit || order.OrderType == OrderType.LimitOnClose)
{
if ((order.TransactionType == TransactionType.Buy) && ((fillPrice - limitFilterAmount) < curPrice)){
return false;
}
return true;
}
Another backtesting issue arose around setting position priority. I implemented the position priority per other posts and it is working as described with the exception of limit orders for the following bar. That is, in order to set priorities correctly, I need to see the next bar open in MySystem; this is relevant for example in limit buys where if the limitprice > next bar open the position will always be filled under these conditions...the order's priority should be set to the highest available in the system. The reverse is true for limit sells.
Any thoughts on how to implement?
Thanks, Duane
|
|
|
Posted 1/6/2010 15:12:26
|
|
|
|
Daniel, any thoughts on the above. The position priority is important because the back testing results may be skewed if the priorities are not set correctly.
Thanks, Duane
|
|
|
Posted 1/18/2010 23:38:59
|
|
|
|
Sorry it took me a while to reply to this.
Your logic looks like it will work. If the bGap parameter is true, the fill price might be equal to the current price, which would mean you would filter out the fill. However, it's possible that the actual limit price of the order was far enough away from the current price that you still would want to fill it. So you might want to check for that position and change the fill price instead of preventing the fill in that case.
You might want to make this logic work for a limit cover also, if you are going to be dealing with short positions.
As far as order priority goes, you can override the GetOrderedOrders method in your paper broker. Call the base method and then sort what it returns so that the higher priority orders come first. It will probably be a bit tricky because you will want to know what the current price is for each symbol to know how to sort the orders. You probably want to save this information to a class variable in overrides of the SimBar and SimTick methods (and any others which send price information), then call the base version of those methods. In the GetOrderedOrders you should be able to use the saved price information to help you sort the orders.
Thanks,
Daniel
|
|
|
|