Adding Position.Priority to a system
Author: mikesblack
Creation Date: 2/11/2016 12:48 PM
profile picture

mikesblack

#1
I'm still trying to get a handle on applying logic to my systems. For example, using if, if else, else, and, or I think I have a good understanding of; however the following system versions produce significantly different results.

The two systems that follow are titled "Official with Priority" and Official 2 11 16 - 1-16 2016. The back tests were done on the S and P 500, all data and with position priority sizers."Official" produced14,870 trades while the first system produced 4486 trades.

In addition, these two systems were written very differently, and as such it seems obvious the results are based on different sets of logic.

My intention is to sell based on two grouped conditions that are OR based. The same for the buy signals, two that are or should be OR based.

Will you help me understand this better? While "Official" has superior results, I wish to re write this system and adopt position.priority to it.

Thank you very much for your help with this.

Official
CODE:
Please log in to see this code.

System # 2 "Official with Priority"
CODE:
Please log in to see this code.
profile picture

Cone

#2
Apart from the difference in assigning priority (random by default in Official 2 2 16), the big difference is two-fold:

Entry Logic
Official 2 2 16: Buys a position for the first condition and can buy ANOTHER position for the second condition too.
Official With Priority: Tests the second condition to buy ONLY if the first condition fails.

Exit Logic
Official 2 2 16: Sells if EITHER condition is true.
Official With Priority: Tests the second condition to sell ONLY if the first condition fails.

Aside:
With "Official 2 2 16" it's unfortunate that the Strategy Wizard puts the exit logic after the entry logic. Where entry and exit conditions are not mutually exclusive, this could result in opening and closing positions on the same bar. Nonetheless, this is not the problem here.
profile picture

mikesblack

#3
Thanks Robert. How can I change " Official with Priority" to buy and sell if either condition is true? Would I group the buy rules with || as I did with " Official"? With the sell rules would I replace else with an if statement?
profile picture

Cone

#4
In the Strategy Wizard, insert an "OR Divider" (find it atop the list of conditions) between conditions that you want OR'd. In other words, if (this OR that) is true, then do something.

If you don't insert an OR, adjacent conditions are automatically "AND'd". A logical AND (e.g., this && that) is for all practical purposes the same as the following programming structure:

CODE:
Please log in to see this code.
profile picture

mikesblack

#5
My confusion comes from the idea that "ands" reduce the number of options available and that "ors" increase the number of options. With Official, back tests produce more trades and " Official with priority" produces less trades. As you explained in your previous post, both entry and exit logic are "ands" for Official, and visa versa with Official with priority. This seems counter intuitive.
I'll re write Official as per your explanations and hopefully figure out the logic in the process. Thanks again for your help.
profile picture

mikesblack

#6
From the Strategy Wizard the resulting code is:
CODE:
Please log in to see this code.

I wanted to maintain the names for each specific sell signal that the preceding code does not allow. Below is the exit logic I used.
CODE:
Please log in to see this code.

Now I have exits with names as desired and buy signals that came from the Strategy Wizard. The performance and number of trades are nearly the same, but not exactly the same. My exit logic might need correction. Can you tell if this is the case?
profile picture

mikesblack

#7
Testing on the S and P 500 shows even more of a difference than the back tests I did on the Dow. The modified system I wrote is showing 5108 trades while the Official system shows 6200 trades. So it seems my logic is off.
profile picture

Cone

#8
The only difference is that you're probably using Portfolio Simulation without assigning priority, therefore the results will be random.

Also, in your logic, the variable use of cond1 and cond2 does absolutely nothing. You even went out of your way to make the editor indent cond# = true; That statement is not modified by the if clause.

CODE:
Please log in to see this code.


The Strategy Wizard uses those temporary cond# variables in a verbose way as a way to combine logical conditions for wizard programming. You'll almost never need to do that .
profile picture

mikesblack

#9
Thanks. I thought that was the case.
When I used the editor, the resulting code is much different depending on if it is a single or multiple position system. With the former:
CODE:
Please log in to see this code.



With multiple positions selected:
CODE:
Please log in to see this code.

The multiple open position option has the buy signals first and includes
CODE:
Please log in to see this code.
loop for the sell signals block. Does this loop prevent the action of selling and buying on the same bar as you indicated earlier?
Can one can reverse the order for the buy and sell signals for the multiple position option? Does it mater? Thanks
profile picture

Cone

#10
QUOTE:
Does this loop prevent the action of selling and buying on the same bar as you indicated earlier?

No.

QUOTE:
Can one can reverse the order for the buy and sell signals for the multiple position option? Does it mater?
It can matter depending on what precisely you need to test or do. However, generally, I would put exit logic after the entry logic only if needed logic that enters and exits on the same bar (like a protective stop). But you still have to know what you're doing! For example, it's not possible to properly test a limit entry and a stop (or market) exit on the same bar.


But wait a minute!
The Strategy Wizard could not have output that code for multiple positions. You added the "LastActivePosition" logic, right? That's an error.
profile picture

mikesblack

#11
I actually copied the code that was created from the Wizard, with multiple positions allowed. The code you see above was not modified in any way. So now I need to figure out how to reverse the order. Still unclear about the "LastActivePosition" logic and how and if it fits in to my system. Check this out for yourself. I included a PDF of the rules. The specific parameters is found in the code.

Below is the code for the same system for single position. Here, exits first and buys last. The results of running one vs the other is significant, with the multi position option creating more trades than the single position option. The results from the multi positions option produces better rates of return, but has significantly greater exposure. Either way, I just want to understand the differences so I can apply the logic in a way that makes sense.
CODE:
Please log in to see this code.
profile picture

Cone

#12
Re: if (LastActivePosition != null && LastActivePosition.Active)

The rule that's inserting that code is "Current open Position is older than a number of bars", and whose description is:
This rule is true when the most recent open Position is older than a number of Bars that you specify,

Consequently, per the description, testing LastActivePosition.Active is correct, but it's probably not what you want for multiple position logic. If you want the timeout to be Position-based, you need to replace LastActivePosition with the p variable (3 places).

Although that rule will work fine with single-position logic, I think it's too ambiguous to use for multiple positions since "Current open Position" should always refer to the Position that is being tested.
profile picture

mikesblack

#13
QUOTE:
Re: if (LastActivePosition != null && LastActivePosition.Active)

The rule that's inserting that code is "Current open Position is older than a number of bars", and whose description is:
This rule is true when the most recent open Position is older than a number of Bars that you specify,

Consequently, per the description, testing LastActivePosition.Active is correct, but it's probably not what you want for multiple position logic. If you want the timeout to be Position-based, you need to replace LastActivePosition with the p variable (3 places).


I think I understand the first part of your post. Can you show me by an example of what you mean by
QUOTE:
you need to replace LastActivePosition with the p variable (3 places)
That will help me to understand this better. Thanks.
profile picture

Cone

#14
In the Multi-Position script...

CODE:
Please log in to see this code.

profile picture

mikesblack

#15
Thank you Robert. By changing the code this way, what happens? I'm unclear what the difference between LastActivePosition and p.Active is.
profile picture

Eugene

#16
Note how the "p" is defined. In the context of a single-position system like this, LastPosition is identical to LastActivePosition.
profile picture

Cone

#17
LastActivePosition is [always] the Last Position that is [still] Active.

1. Assume that your strategy bought MSFT three times: on bars 11, 12, and 13. We'll call these Positions 1, 2, and 3, respectively.
2. On bar 14, the exit logic will process all three positions. Remember, that's what this loop does:
CODE:
Please log in to see this code.


3. Question: Which of the three is the LastActivePosition?
4. Right: Position 3
5. How "old" is it on bar 14? Answer: 1 bar.

Consequently, if you had intended to sell Position 1 after 3 bars, it's not going to work if you're testing LastActivePosition. You need to be testing the current Position p.
profile picture

mikesblack

#18
Thank you Robert and Eugene. I'm beginning to understand.
This website uses cookies to improve your experience. We'll assume you're ok with that, but you can opt-out if you wish (Read more).