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

Edward Wilson edward.wilson at hotmail.co.uk
Thu Jan 19 09:59:56 CET 2017


Thanks for the detailed response Brian!


I believe the custom ruleSignal is going to be the solution.


Ed


________________________________
From: R-SIG-Finance <r-sig-finance-bounces at r-project.org> on behalf of Brian G. Peterson <brian at braverock.com>
Sent: Sunday, 15 January 2017 10:30 PM
To: r-sig-finance at r-project.org
Subject: Re: [R-SIG-Finance] 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/
Brian G. Peterson<http://braverock.com/brian/>
braverock.com
BRIAN G. PETERSON 773-459-4973. brian at braverock.com. download resume as PDF SUMMARY. Senior quantitative trader, financial analyst, technical architect, and project ...



Ph: 773-459-4973
IM: bgpbraverock

_______________________________________________
R-SIG-Finance at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-sig-finance
R-SIG-Finance Info Page - Seminar for Statistics | ETH Zurich<https://stat.ethz.ch/mailman/listinfo/r-sig-finance>
stat.ethz.ch
To see the collection of prior postings to the list, visit the R-SIG-Finance Archives. Using R-SIG-Finance: To post a message to all the list members ...



-- Subscriber-posting only. If you want to post, subscribe first.
-- Also note that this is not the r-help list where general R questions should go.

	[[alternative HTML version deleted]]



More information about the R-SIG-Finance mailing list