Summary of issue: The Advanced Position Sizer/ Pyramiding/ Reverse Incremental sizer is not incrementing position size correctly when there is more than one position to be opened on a bar.
Test code:
Position Sizer settings:
Details of Positions created:
Debug log to show what Position count the sizer is using:
Observations:
- Position size of 1st Position is correct
- Position size of 2nd Position (taken on another bar) is also correct - it gets incremented by 50% as per settings
- Position size of all subsequent Positions on that bar should have been incremented by 50% over previous position's but is not; this is happening because the Position sizer is not updating the Position count as it should after opening each new position
Note: I *only* checked the Reverse Incremental Pyramiding Position Sizer, can't comment on any other sizer that may also be using Position count for its calculations.
Test code:
CODE:
using WealthLab.Backtest; using System; using WealthLab.Core; using WealthLab.Indicators; using System.Collections.Generic; namespace WealthScript13 { public class MyStrategy : UserStrategyBase { //create indicators and other objects here, this is executed prior to the main trading loop public override void Initialize(BarHistory bars) { } //execute the strategy rules here, this is executed once for each bar in the backtest history public override void Execute(BarHistory bars, int idx) { if (OpenPositions.Count < 5) { if (OpenPositions.Count == 0) //there's no open Position { if (idx == bars.Count - 20) { PlaceTrade(bars, TransactionType.Buy, OrderType.Market, 0, "P1, Initial Position"); WriteToDebugLog(bars.DateTimes[idx].ToShortDateString() + "\t" + "OpenPositionCt =" + "\t" + OpenPositions.Count); } } else { int n = 4; for (int j = 0; j < n; j++) { PlaceTrade(bars, TransactionType.Buy, OrderType.Market); WriteToDebugLog(bars.DateTimes[idx].ToShortDateString() + "\t" + "OpenPositionCt =" + "\t" + OpenPositions.Count); } } } } //declare private variables below } }
Position Sizer settings:
Details of Positions created:
Debug log to show what Position count the sizer is using:
Observations:
- Position size of 1st Position is correct
- Position size of 2nd Position (taken on another bar) is also correct - it gets incremented by 50% as per settings
- Position size of all subsequent Positions on that bar should have been incremented by 50% over previous position's but is not; this is happening because the Position sizer is not updating the Position count as it should after opening each new position
Note: I *only* checked the Reverse Incremental Pyramiding Position Sizer, can't comment on any other sizer that may also be using Position count for its calculations.
Rename
QUOTE:There are only transactions, not positions on the signal bar. This works differently than it did in legacy versions of WealthLab - you don't have access to positions before the bar on which they're created.
Posn sizer is not updating the Posn count as it should after opening each new position
If the idea here is to "scale in" with different sizes on the same bar in order to exit Positions with different sizes, you won't be able to do it by pyramiding. There are other ways you could do it by playing with Transaction.Quantity, but for this scenario it seems most logical to buy one large position and scale out by adjusting the Transaction.Quantity for the exits.
The Position Sizer actually does have access to them via its Candidates property.
That said, the intent of this Position Sizer is to clearly manage multiple positions on SEPARATE bars. If you’d like to also have it apply to multiple positions on the same bar we might consider an enhancement.
That said, the intent of this Position Sizer is to clearly manage multiple positions on SEPARATE bars. If you’d like to also have it apply to multiple positions on the same bar we might consider an enhancement.
@Glitch:
YES, please!!!
P.S. Ditto for Strategy or Strategy Monitor generated signals, too.
QUOTE:
...apply to multiple positions on the same bar...
YES, please!!!
P.S. Ditto for Strategy or Strategy Monitor generated signals, too.
QUOTE:
but for this scenario it seems most logical to buy one large position and scale out by adjusting the Transaction.Quantity for the exits.
I agree with @Cone: the script-based approach he suggested seems more appropriate, simple and less risky than modifying the PosSizer that works well for what it's been designed.
What's the practical use case for creating pyramided positions on the same bar? I was "reaching" when the only thing I could imagine was setting up sizing for exits. Do you have something else?
It's meant to "load up with size" when an exceptional opportunity arises.
For example, when an indicator craters (or spikes) below (above) some value an extra position is taken for each decrement (increment) by xx points { 'n' gets calculated here } - up to the max number of positions.
This task is most easily and reliably handled by this particular Position Sizer. It works flawlessly in WL6.
For example, when an indicator craters (or spikes) below (above) some value an extra position is taken for each decrement (increment) by xx points { 'n' gets calculated here } - up to the max number of positions.
This task is most easily and reliably handled by this particular Position Sizer. It works flawlessly in WL6.
(Somebody deleted my last post, posting it again)
@Glitch,
Counting on you to follow through.
@Glitch,
QUOTE:
If you’d like to also have it apply to multiple positions on the same bar we might consider an enhancement.
Counting on you to follow through.
I tagged this as a FeatureRequest so it's now in the wish list!
Thanks... even though I realize it's a diplomatic way of saying No.
It's just that I have a major initiative in the works now so can't work on this at this very moment. It's now logged so we won't lose track of it, and it may take some time but we'll get it it.
QUOTE:
(Somebody deleted my last post, posting it again)
I did it because your post had no payload and its only purpose was to bump up the topic. 🤷♂️
@Eugene
I'd posted just to make sure Glitch gets to read it, wasn't trying to bump it up.
I'd posted just to make sure Glitch gets to read it, wasn't trying to bump it up.
Your Response
Post
Edit Post
Login is required