Adding Position.Priority to Limit orders
Author: mikesblack
Creation Date: 4/20/2016 4:42 PM
profile picture

mikesblack

#1
While inspecting one of the trading systems "Wider P Bands" I notice that when trades get executed, those trades are seemingly coming from randomly assorted Signal Names(Priority). I have Position Priority set up, yet the trades chosen is not in atrp reverse order.

I have been trading this system by using the top 16 atrp priority stocks. Does WL select the proper number of stocks based on percentage of equity = 6 percent or will every stock with a signal require a buy at limit? If the answer is I would have to buy each Alert would be practically speaking, too long. In addition, how can this system select priority positions?

Here is the code for the buy and sells:
CODE:
Please log in to see this code.
profile picture

Eugene

#2
Position.Priority is assigned correctly here. Trades come in the correct order. Something to keep in mind: Priority value in signal name column in Alerts/Trades is not ordering from low to high
profile picture

mikesblack

#3
Will I need to buy all symbols to pick up the same as system stocks or what other way is there?
profile picture

Cone

#4
The only proper way to assign Position.Priority to limit and stop order is by the time of day that they're executed. See this wiki article for all the info and solutions: Setting Priority for AtStop/AtLimit Orders
profile picture

mikesblack

#5
Thanks Robert, I would like to use ATRP Bars, 5 to determine which positions get priority rather than time of day.. Wouldn't that be an example of peeking? Will I need to buy all limit orders to cover those positions that get hit? Obviously, with 500 potential limit orders that would take too much time to make orders from. Priority buys isn't necessary, but knowing that at 6 percent of equity buys be 16 positions, I'd like to place orders on these, which ever they are.
profile picture

Cone

#6
QUOTE:
Wouldn't that be an example of peeking?
Using anything other than time of day for stop/limit orders is unrealistic (not peeking). Example:

1. Assuming you're trading a EOD system and on a given day you have $10,000 buying power and sizing with $2,000 per position.
2. The strategy generates 50 limit orders.
3. 10 of these orders hit their limit prices, so there are 10 trades candidate to choose from in the backtest.

The question is, "which 5 of these 10 trades should the simulation execute?"

4. Realistically, the answer is: the first 5 trades that occurred chronologically, or, time of day. (Actually the priority is the inverse time of day so that orders execute at 0931 have more priority than those that occurred at 1559.

One thing you can do realistically is to add an ATRP filter for which limit orders are generated by the Strategy. e.g., if (atrp[bar] > 2.0) BuyAtLimit(... Even so, in the example above, maybe the Strategy generates 35 instead of 50 orders. So there remains a lack of buying power for all trades and the same situation arises.

Lastly, you can forget about Position priority altogether and use the Monte Carlo-Lab visualizer. Select the "Same Date Scramble" option, and then you'll get a histogram of the result of many simulations that essentially scramble the trade priority for a specific day (bar). This is a better way to analyze a limit strategy than to rely on the result of a single (albeit realistic) simulation that used the correct Position priority.
profile picture

mikesblack

#7
I am trading 200,000 with 6 percent sizing. Typically this system kicks out 500 alerts, depending on how many stocks are already in the market. So, 4-500 possible trades. I don't understand how to narrow down the selection to 16 stocks. Is there a way? Thank you for your help.
profile picture

Cone

#8
a. To trade this strategy, the idea is that you enter all the orders.
b. When 16 of them hit the limit trigger, you quit trading. (Careful, on a "bad day" many more than 16 could hit right on the open.)
c. In a backtest, those 16 should be the first ones that reach the limit price chronologically, i.e., by time of day (see link in my post #4 to learn how to set priority by time of day.)
d. If you're not using margin, Wealth-Lab won't allow more than 16 trades with 6% sizing. That part you need not worry about.
profile picture

mikesblack

#9
I tried to code both the "IntradayFillPriorityEstimate" and the "LimitPriorityLong"; however, I am unable to compile this code. Using the above code, can you help me code this properly? As per entering all open orders, we are looking at 500 or so alerts that unless I have an automated way of trading, would be a very long process indeed.
profile picture

Eugene

#10
QUOTE:
however, I am unable to compile this code

Install Community Components and restart WLP. If still seeing a compilation error, don't hesitate to type in its text here or paste your code line that's causing it.
profile picture

Cone

#11
QUOTE:
we are looking at 500 or so alerts that unless I have an automated way of trading, would be a very long process indeed.
1. Are you a Fidelity customer?

2. In the Alerts view, Select All > Monitor in Quotes Window.
There, the orders that you need to enter will trigger when they attain the limit price. Even so, at times you'll have to be quick to get your order entered in time (set a Trigger Threshold below 100 to trigger earlier). Read all about it in the User Guide: Quotes chapter.
profile picture

mikesblack

#12
Yes I am. I will look into number 2. Thanks Robert for your help. I actually changed things up by adding some filters. Now I am seeing 10-20 alerts, not 500. Good results.
profile picture

mikesblack

#13
I'm only showing a paper account option and not my actual accounts. There are two accounts that I am trading, both the same for myself and for my mom. I am able to select at least one of the real accounts; however when I select all, the trades are showing in a paper account. BTW: Both accounts are margin accounts that from the description, I may be unable to trade. Is this correct? Further clarity would be greatly appreciated.

You might wish to move this to a new thread as it is off the original topic.
profile picture

marcomaier

#14
Hello,

I want to test an new EOD-strategy with BuyAtLimit-Entry.

And I want to represent the required logic, explained on the basis of an example:

The DataSet consists of 500 stocks. The strategy has different conditions to become an alert. Let's say we have in a specific day 15 alerts, that means 15 stocks that fulfill the conditions. Additional we have an priority. How can I determine that only maximum the first 5 prioritized stocks are considered to become an potencially entry? That means if there are 15 alerts I want to check if only the first 5 prioritized stocks reach the limit Price, not the following 10 stocks. The Background is that I only want to place maximum 5 Limit orders at the Broker. If for instance only 2 limit orders are executed is not relevant.

Is it possible with the Position Options Positionsizer and with the function: "Reject a Position when candidate trade count (number of Alerts) is above or below some Alert cutoff threshold"?

Thanks
profile picture

Eugene

#15
Hi Marco,

Yes, "Reject on Alerts >" in said PosSizer should reject positions above some threshold when the candidate count exceeds it. Note, however, that this won't work for Alerts due to a long-standing bug (Open Issues > (62853) In PosSizers, the Candidates list is empty for Alert sizing) - but should do so for backtest. Also, it sounds like built-in "Max Entries Per Day" PosSizer might fit your requirement.
profile picture

marcomaier

#16
Very good, thank you ...
profile picture

Eugene

#17
QUOTE:
Yes, "Reject on Alerts >" in said PosSizer should reject positions above some threshold when the candidate count exceeds it. Note, however, that this won't work for Alerts due to a long-standing bug (Open Issues > (62853) In PosSizers, the Candidates list is empty for Alert sizing) - but should do so for backtest. Also, it sounds like built-in "Max Entries Per Day" PosSizer might fit your requirement.


UPDATE:
This bug will be fixed in WLD 6.9.24. No ETA at the moment as we're still trying to fix an issue with this build.
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).