Quantstrat: Creating a custom function to track closed orders

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Quantstrat: Creating a custom function to track closed orders

EdWilson
Hi all,


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?


Many thanks

Ed Wilson


        [[alternative HTML version deleted]]

_______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-sig-finance
-- 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.
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Quantstrat: Creating a custom function to track closed orders

braverock
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

_______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-sig-finance
-- 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.
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Quantstrat: Creating a custom function to track closed orders

EdWilson
Thanks for the detailed response Brian!


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


Ed


________________________________
From: R-SIG-Finance <[hidden email]> on behalf of Brian G. Peterson <[hidden email]>
Sent: Sunday, 15 January 2017 10:30 PM
To: [hidden email]
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. [hidden email]. download resume as PDF SUMMARY. Senior quantitative trader, financial analyst, technical architect, and project ...



Ph: 773-459-4973
IM: bgpbraverock

_______________________________________________
[hidden email] 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]]

_______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-sig-finance
-- 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.
Loading...