Quantstrat: Creating a custom function to track closed orders
On 01/14/2017 11:06 PM, Edward Wilson wrote:
I have a strategy which involves multiple entry/exit levels that can be enabled/disabled dynamically depending upon the fills of the other entry/exit levels in the strategy (along with some other variables). The way I would like to achieve this is to have a state machine to control the states of each entry/exit Level which can then be checked within my custom rule signal function. At the moment, I'm planning to call the state machine from within the applyRules function if ruleOrderProc returns some closed orders, and pass in the order label as the identifier. My question is: Is this the best approach, or maybe there is is a better way to achieve this result built into quantstrat already?
Yes, I think you may be over complicating things. applyRules already implements a state machine. Unlike indicators or signals, which are typically applied in a vectorized fashion, the rules are evaluated in a path (state) dependent way. Each rule has access to the entire current state at a point in time for that instrument (or for all instruments if it is a rebalancing rule). So, in this context, there are a few ways you could do what you want. The simplest way would be to write an order sizing function which checks closed orders and their labels before deciding on order sizing for the current rule. You'll know the label of the rule currently under evaluation, and have access to all order history up to this point. A more complicated way would be to create a custom version of ruleSignal. I originally thought ruleSignal would just be an example, and that we would need to write custom versions for each strategy. In practice, we've mostly just ended up using ruleSignal as-is, but that doesn't preclude you from using a custom version. like the order sizing option discussed above, your custom ruleSignal would have access to the current state: position, closed orders, open orders, etc., and can make decisions about whether to do anything with the current signal. This option is more complicated than working inside the order sizing function, as there are more variables to juggle, and you'd need to manage entering orders directly, among other things. I would recommend against modifying ruleOrderProc. You'd rather not enter orders that you don't want to get filled. A final way I'll discuss which may or may not apply in your case is to pre-process the signals. The goal here would be to preemptively reduce the number of signals passed on to the rules for processing in a path and state dependent fashion. Typically the way we would implement such a filter would be as another signal function. Each signal function has access to the output of any signal functions called previously, so it is easy to put a signal filter on the list of signal functions at the end. This filter function can either add more signal columns filtered from the original signals, or even just modify the original signal columns (this may be slightly faster, but makes things harder to track). In summary, I'd likely recommend implementing your state checks in an order sizing function. I think it would require touching the least code and isolate your state-dependent logic for your strategy at the point you are deciding whether to place an order, and for how much quantity. Regards, Brian
Brian G. Peterson http://braverock.com/brian/ Ph: 773-459-4973 IM: bgpbraverock