Skip to content

quanstrat rule to exit same day close (using daily data)

10 messages · G See, Brian G. Peterson, S +1 more

S
#
I am trying to backtest a strategy that requires an exit on the close (same
day as the entry).  I have searched through Rmetrics and stackoverflow and
found the following post:

http://stackoverflow.com/questions/10441614/quantstrat-in-r-setting-a-date-based-exit-signal

Brian Peterson said the following:
not designed for filters based trades really.
Set the delay to be one day, and the prefer
argument to prefer a different price column.
your problem.

Now this was a solution to exit at a future time stamp. I want to exit the
*same* day (I am using daily data for my test) which is why I'm not sure if
setting a delay really works for what I want to do. Is this at all possible?

Appreciate the direction.


--
View this message in context: http://r.789695.n4.nabble.com/quanstrat-rule-to-exit-same-day-close-using-daily-data-tp4629612.html
Sent from the Rmetrics mailing list archive at Nabble.com.
#
In quantstrat, if your have a signal on bar t, the rule will be executed 
at bar t+1. In your case, this means that the order will be added for 
the next day.

Use the 'prefer'-argument to specify which of next day's rates (open, 
low, high, close) you want to use.
On 12-05-12 23:45, algotr8der wrote:

  
    
#
Extending on what Jan said, perhaps you could add a "PrevClose" column
to your data and use prefer='PrevClose'

Garrett
On Sun, May 13, 2012 at 2:55 PM, s p <algotr8der at gmail.com> wrote:
#
On Sun, 2012-05-13 at 15:55 -0400, s p wrote:
Sure you can, if the signal is on the same observation.  

I'm not sure how realistic a backtest of market on open and market on
close is going to be, of course, because of slippage, but it should
'work' in quantstrat.

Your entry rule would use prefer='Open' and your exit rule would use
prefer='Close'.
#
Brian,

I can't get that to work.  It used to be that exit orders would fire
before enter orders and if you did not have a position, they were
effectively not sent.

I tried to test this by making a tiny change to the maCross.R demo.  I
changed the second add.signal call so that it had
    relationship="gte"
just like the first add.signal call.  In other words, you should get
an enter and exit at the same time.  So, you should never have a
position.  Nevertheless,  you end up with a position of short 600
shares.  If that's not right, then I doubt that adding prefer="Open"
to one and prefer="Close" to the other will work.

Garrett
On Sun, May 13, 2012 at 3:20 PM, Brian G. Peterson <brian at braverock.com> wrote:
#
Garrett is correct, sorry, I'm still a little sleep-deprived from
R/Finance.  

Rule execution order is discussed in the documentation for add.rule, and
'enter' rules are processed last.

I wonder if we should consider moving 'rebalance' rules to the end of
the order, or adding a exit rule type that is specifically evaluated
after entry rules.   The code change would be trivial, as that is
processed in a switch statement.
On Sun, 2012-05-13 at 15:46 -0500, G See wrote:

  
    
1 day later
#
On Tue, 2012-05-15 at 09:45 -0700, algotr8der wrote:
OK, it's a one or two line change (order of rule execution) , I'll work
on it.

Jan Humme (opentrades) has a patch basically completed that will allow
multiple trades on the same bar, though things may of course happen 'out
of order' depending on the order of rule evaluation operations.

Regards,

   - Brian
1 day later
#
Garrett,
On 15-05-12 19:02, Brian G. Peterson wrote:
Yep, patch committed now, rev 1025. There was a problem with the new 
orderset feature (committed a couple of weeks ago), causing the 
enter-orders to be canceled.

This leaves us with the following situation:

=> if you use a hard-coded order position for the exit-order (eg, -100) 
this will still be ruthlessly followed; the order size will not be 
adjusted to match the (max) current position. As a result, you will end 
up with a -100 position after the first exit order gets executed. 
However with your modification (lt changed to gte) the enter order will 
be executed at the same bar, leaving you with a 0-position again.
=> if you use the 'all'-argument for the exit-order, the first 
exit-order will be skipped due to the 0-position, but the first 
enter-order (on the same bar) will be executed. In this case you end up 
with a 100-position, which will be exited and immediately entered again 
at the next bar that has a signal.
Best regards,