SetShareSize gives an alert for 0 shares
Author: DaveAronow
Creation Date: 2/9/2010 7:11 PM
profile picture

DaveAronow

#1
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.
profile picture

Eugene

#2
No, you're no missing anything. It's a bug. Thank you Dave.
profile picture

HendersonTrader

#3
Are there any plans to fix this bug?
profile picture

Eugene

#4
Hopefully, in the upcoming version later this month.
profile picture

HendersonTrader

#5
Great! Thanks.
profile picture

Eugene

#6
Hopefully is the key, this bug fix is in the works.
profile picture

Cone

#7
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.
profile picture

HendersonTrader

#8
"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!
profile picture

Cone

#9
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.
profile picture

Cone

#10
We've avoided disaster: SetShareSize is fully fixed for the upcoming release.
profile picture

HendersonTrader

#11
That is absolutely fantastic. Thank you very much for the follow-up.
profile picture

dansmo

#12
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.
profile picture

Eugene

#13
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.

Edit
QUOTE:
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).
profile picture

dansmo

#14
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.
Edit
I think that there should be a general solution for dealing with this.
profile picture

Eugene

#15
OK I was reinventing the wheel here. See this FAQ for a solution:

How to pass a value from Strategy to PosSizer for Alert sizing?
profile picture

Eugene

#16
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.
profile picture

dansmo

#17
@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?
profile picture

Eugene

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

dansmo

#19
How can I get the Alerts Basisprice?
The PosSizer uses currentPos.BasisPrice which is of course not available in this situation.
profile picture

Eugene

#20
You can't. I explained yesterday.
profile picture

dansmo

#21
Okay, so I´ll have to put that in the Bars.Tag, too?
profile picture

Eugene

#22
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.



profile picture

dansmo

#23
Thats even better. Thanks for your suggestion.
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).