When I run the following script (or the more complex one I discovered it with) with position sizing set to WealthScript Override (SetShareSize) the alert share quantity is always zero (trades do execute properly in the backtest though). Is this a bug or something I'm missing?
Dave
P.S. Alerts to exit trades seem to give the correct amount
CODE:
Please log in to see this code.
Size:
Color:
No, you're no missing anything. It's a bug. Thank you Dave.
Size:
Color:
Are there any plans to fix this bug?
Size:
Color:
Hopefully, in the upcoming version later this month.
Size:
Color:
Great! Thanks.
Size:
Color:
Hopefully is the key, this bug fix is in the works.
Size:
Color:
In the current state, there's at least a "partial fix" (an Alert will have the number of shares of the previous Position), but hopefully that can be worked out before the release. Not sure.
Size:
Color:
"there's at least a "partial fix" (an Alert will have the number of shares of the previous Position)"
That would be a disaster for anyone using the feature to avoid exceeding Day Trade Buying Power at Fidelity. Fidelity permits full use of IBP, which usually exceeds DTBP. Day trade margin calls are very painful!
Size:
Color:
It just means that if you don't really use "dynamic sizing", at least this will work for this single case. Anyone else shouldn't use it, unless it "works as designed". There's still a desire to fix the bug and a small window to do it. If the User Guide doesn't indicate that it's fixed in the "New and Noteworthy > What's Changed" topic, ask here for a confirmation before putting it to use, or just test it yourself.
Size:
Color:
We've avoided disaster: SetShareSize is fully fixed for the upcoming release.
Size:
Color:
That is absolutely fantastic. Thank you very much for the follow-up.
Size:
Color:
When I run a script in combination with my PosSizer Entry Alerts show a Qty od 0 whereas Exit Alters show size and the Trades show the correct size, too. Is this still in the works?
Edit: I think it may have something to do with the following:
CODE:
Please log in to see this code.
The PosSizer uses the positions.Tag feature. The alert seems to be generated
before the position size is calculated. Right?
What would be a better way to do this? Position.Tag seems to be useless in a realtime environment then.
Size:
Color:
QUOTE:
When I run a script in combination with my PosSizer Entry Alerts show a Qty od 0 whereas Exit Alters show size and the Trades show the correct size, too. Is this still in the works?
No it's been fixed long ago. Now returning a zero-sized Alert entirely depends on your PosSizer. Here's what's most likely happening inside your PosSizer:
1. To size a Position, you need to rely on some data contained in one of the properties of the Position object (
currentPos) e.g. Tag
2. By design,
currentPos is null when sizing for entry Alerts.
3. To avoid getting a runtime error, you check that
currentPos is !=
null before querying the Position properties (p.1), and return 0.
EditQUOTE:
Position.Tag seems to be useless in a realtime environment then.
As mentioned above,
currentPos is null when sizing for entry Alerts. It's by design: the Position doesn't exist yet. Hence, no properties of the object (including but not limited to .Tag) can be accessed when sizing for Alerts while the Position hasn't been established yet.
As a workaround, you might want to try passing the information when sizing for entry Alerts (i.e.
currentPos == null in PosSizers and
bar+1 == Bars.Count-1in your Strategy) in some other fashion (e.g. save the "factor"
to a CSV file and read it back in the PosSizer).
Size:
Color:
QUOTE:
As a workaround, you might want to try passing the information when sizing for entry Alerts (i.e. currentPos == null in PosSizers and bar+1 == Bars.Count-1in your Strategy) in some other fashion (e.g. save the "factor"
to a CSV file and read it back in the PosSizer).
Could you be a bit more detailed about your prposed workaround, I dont understand it.
EditI think that there should be a general solution for dealing with this.
Size:
Color:
Size:
Color:
The trick when sizing for entry Alerts is to do it a little bit differently:
CODE:
Please log in to see this code.
The next step (your PosSizer) is exemplified in the QuickRef: see
Bars.Tag.
You might wonder why; the answer comes when you realize that the Position returned by BuyAtLimit on the last bar -- the one that gave an Alert -- is
null.
Size:
Color:
@Eugene
I need your help with that one. Now, Qty is not 0, but all my entry limits are shown twice in the Alerts tab:
CODE:
Please log in to see this code.
Why is that?
Size:
Color:
Try this:
CODE:
Please log in to see this code.
Size:
Color:
How can I get the Alerts Basisprice?
The PosSizer uses currentPos.BasisPrice which is of course not available in this situation.
Size:
Color:
You can't. I explained yesterday.
Size:
Color:
Okay, so I´ll have to put that in the Bars.Tag, too?
Size:
Color:
Why not. You may even devise a struct/class that holds several properties at a time i.e. custom Type. Something like this:
CODE:
Please log in to see this code.
Size:
Color:
Thats even better. Thanks for your suggestion.
Size:
Color: