Will PosSizers of WL5.6 have a CandidateCount function which can distinguish between “Long” and “Short” alerts?

That wouldn't be baseline, so it's probably not planned, but we'll drop the hint.

I am thinking about something like this:

Many (may be 12) rows of the following groups:

Dropdown arrow that allows you to choose between “Long Candidate Count” and “Short Candidate Count”, “From”, “To”, dropdown arrow that allows you to choose between “Long Position Size %” and “Short Position Size%”, “Maximum Number Positions (of the current chosen side (row))”, and a checkbox to activate the row.

This setting would allow to set short or long position size according to number of short or long alerts. For example, it would be possible to set position size of the short alerts according to number of long alerts and vice versa. In addition, this would allow to set percentage of equity invested in short and long positions at the same time.

What are the "rows" and "groups"? I don't seem like I've understood your idea. And what's "From" and "To"? Could you please elaborate?

I looked on your implementation of adjusting position size based on priority and thought it could be done the same way:

/Forum/Posts/Pos-Sizer-Question-How-do-I-adjust-position-size-based-on-priority-30206

Let us try to do the following:

Trading system generates long and short signals at the same day while scanning a portfolio.

We want the back-tester to invest 70% of the equity into long positions and 30% into short positions at the same time.

We want the back-tester to change position size of longs and shorts depending on number of signals in each direction.

Let’s say, if there are 5 or less long signals, we want to include up to 5 signals and those 5 signals should cover the whole 70% of the equity, but if there are 6 or more long signals we want to include in the back-test only first 10, while those 10 cover the whole 70% of the equity.

In order to do that we need to set:

If “LongCandidateCount” “From”=1 “To”=5 then set “Long Position Size %”=14% “Maximum Positions Number”=5;
If “LongCandidateCount” “From”=6 “To”=100 then set “Long Position Size %”=7% “Maximum Positions Number”=10;

Same thing we can do with short signals:

If there are 5 or less short signals, we want to include up to 5 signals and those 5 signals should cover the whole 30% of the equity, but if there are 6 or more short signals we want to include in the back-test only first 10, while those 10 cover the whole 30% of the equity.

In order to do that we need to set:

If “ShortCandidateCount” “From”=1 “To”=5 then set “Short Position Size %”=6% “Maximum Positions Number”=5;
If “ShortCandidateCount” “From”=6 “To”=100 then set “Short Position Size %”=3% “Maximum Positions Number”=10;

Thank you

Hi,

QUOTE:
If “LongCandidateCount” “From”=6 “To”=100 then set “Long Position Size %”=7% “Maximum Positions Number”=10;

What if LongCandidateCount is 500? In other words, exceeds the maximum threshold by a wide margin. I think the PosSizer can take the first 100 signals and drop the rest, without the risk of ending with a position size too small.

Next question:

QUOTE:
If “LongCandidateCount” “From”=1 “To”=5...
If “LongCandidateCount” “From”=6 “To”=100...

What if "To" #1 = 5 and "From" #2 = 7, i.e. there's inconsistent input?

For now, I'll be forcing valid input here to maintain consistency. Otherwise, the PosSizer would not know what to do, and will size all positions to 0, skipping trade creation. Alternatively, introducing a minimum position size could probably do the trick.

Note: initially, you mentioned "12 rows" of From/To pairs -- I'll stick to 2 rows as described in this thread, as going over anything than 2-3 rows complicates the code and overloads the WinForm.

I wrote LongCandidateCount “To”=100 as an example, but actually this number could be any very big number. If we set “Maximum Positions Number”=10, all the rest candidates should be dropped.

For example, if there are 40, 400, or 4000 long candidates and the settings are:

If “LongCandidateCount” “From”=6 “To”=Any very high number (even higher than the number of tickers in the dataset) then set “Long Position Size %”=7% “Maximum Positions Number”=10;

The backtester in the above case should include only first 10 candidates and set 7% for each of them. Namely, 10*7%=70% of the equity will be invested in the long positions.

Yes, I think the consistency between "To" #1 and "From" #2 should be maintained, since otherwise, there would be skipped trades.

Yes, two rows would be enough for now.

Thank you.

QUOTE:
Yes, I think the consistency between "To" #1 and "From" #2 should be maintained, since otherwise, there would be skipped trades.

We'll be showing a warning message in this case. Plus, there's going to be 5 other validity checks (e.g. sum > 100% etc.)

P.S. Any idea on how do we name the PosSizer? There already will be "Spread Cash Equally"

It looks Great!

Just to make sure, what is goanna happen, if there are just three Long Candidates? According to what I was thinking, the Simulator should invest in each long position 14%, totaling 42% in long positions. Namely, 70%/5=14%. 14%*3=42%.
Will it work this way?

Regarding the name, may be "Long and Short Allocator" could be an option?

QUOTE:
According to what I was thinking, the Simulator should invest in each long position 14%, totaling 42% in long positions. Namely, 70%/5=14%. 14%*3=42%.

Yes, exactly like that.

Re: name - sounds good and descriptive, but what about something like "Graded equity percentage"?

I like "Graded equity percentage" too.

So be it. You may create a support ticket, and I'll attach the PosSizer pack once its newer build (with your PosSizer) is ready.

Thank you so much!

While using stop orders (BuyAtStop, ShortAtStop), are all stop orders considered as candidates and should be taken into account while setting "Max positions" column, or just those stops which were triggered the next bar are taken in calculating the position size?

The code works with the standard Candidates list, which "Returns a list of Position objects that represent the candidate Positions that are being sized on the current bar, at the point in time that the SizePosition method is being called."

I am sorry, but could not understand if the not reached stops are taken into considerations.

By definition, Candidates are potential entries - I think all orders for the next bar (bar+1) should be considered; but if I'm mistaken, I'd appreciate if Robert will correct me.

Of course, the "not reached" stops are not taken into consideration - they are not candidate trades. They didn't trigger, they are no Alerts - just give it a thought. By definition, Candidates are potential entries that are being sized at the current bar. All triggered entry stop/limit trades (Alerts) are processed in raw profit mode, and then position sizing constraints apply (assuming portfolio simulation mode).

To PosSizer users out there:

WL 6.3-6.4 has a bug: "(62853) In PosSizers, the Candidates list is empty for Alert sizing". This PosSizer may display 0 sized alerts because of this.

QUOTE:
WL 6.3-6.4 has a bug: "(62853) In PosSizers, the Candidates list is empty for Alert sizing". This PosSizer may display 0 sized alerts because of this.

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.