[R-SIG-Finance] quantstrat - macross demo problem

Brian G. Peterson brian at braverock.com
Wed Jan 26 13:42:25 CET 2011

On 01/25/2011 09:47 PM, Aleksandr Rudnev wrote:
> On Tue, Jan 25, 2011 at 3:54 PM, Stephen Choularton
> <stephen at organicfoodmarkets.com.au>  wrote:
>> ...
>> The rules will be executed by type, in the order listed above.
>> ...
>> Has anyone got this problem and solved it?
> I have seen similar thing, but never had time to trace it before today...
> It seems like a defect in applyRules (if we take mentioned note as a
> spec) or in add.rule, or in ruleOrderProc, depending on how you look
> at it, but I guess authors will comment on that.
> Basically, what's happening is that "rules" list in strategy is
> populated with lists of rules of different type, each of such lists
> ("order", "entry", "exit", etc) is created and added to "rules" when
> add.rule is invoked first time for such type (lazy initialization). In
> applyRules "rules" are iterated in order corresponding to how
> different types of rules were added. In your case you start with
> "enter" type, then add "exit".
> Workaround would to first add "exit" rule(s), then "enter" rule(s).

This is correct.  Thank You for the detailed examination of the code.

The lines in question in applyRules() are a loop around a switch:

l506 and following:

for ( type in names(strategy$rules)){
	switch( type ,

I'll need to think about an alternate formulation in applyRules() that 
would work the rule types in order as described in the documentation 
(which was our intent).

Any input on fixes gladly accepted.


   - Brian

Brian G. Peterson
Ph: 773-459-4973
IM: bgpbraverock

More information about the R-SIG-Finance mailing list