[R-SIG-Finance] Quantstrat: Creating a custom function to track closed orders

[Brian G. Peterson]

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