Hi Eugene,
I run the
Portfolio-wide conditions script example available in the wiki with the following modification
CODE:
Please log in to see this code.
Normally, trade positions must be ended after 1 bar and have a maximum hold position equal to 2.
But when I look on trades sheet, I see several trades with a hold position greater than 2. Can you explain me why? Is it because of the setcontext synchronization logic ?
To reproduce the result, run the script with the modification on the Dow30 dataset with a raw mode.
Thanks for your help
Size:
Color:
Hi Alexandre,
Cone will correct me if I'm wrong (he's the author):
CODE:
Please log in to see this code.
Size:
Color:
Thanks a lot
Size:
Color:
Hi Eugene,
I have another problem when I try to adapt the script to use autostops and priority in positions..
When I run the following strategy with the Dow30 dataset (set 20% of the equity with a first date of 01/01/2000), there is no error :
CODE:
Please log in to see this code.
But with the following script, there is a runtime error (position entry cannot be zero). I run the script with symbol AXP from the Dow30 dataset with same parameters.
CODE:
Please log in to see this code.
Do you see why ?
Size:
Color:
It's because V has a shorter history. To make sure you're using real data in a script like this one, check for the
FirstActualBar.
Just add this after SetContext() -
CODE:
Please log in to see this code.
Size:
Color:
Thanks Cone. I tried it but I see a strange result (see my screenshot). The 4 trades have a the same exit date as the entry date.
Moreover, there are 2 positions for the same symbol (XDM).
Do you see another problem in the code ?
Size:
Color:
Just fyi: AAPL replaced T in the Dow 30 on 19 March 2015.
I can't have the same script that you have. If your data loading range starts on 1/1/2000 and the trading loop starts at bar 30, there's no way that you can get into a trade on 1/3/2000 (bar #2) as indicated in your Trades list. Furthermore, even if you started on bar #1, you couldn't get a CrossOver since the SMA would be 0.
Size:
Color:
This is the script :
CODE:
Please log in to see this code.
Each time I run it, I have the same result displayed in the screenshot. I agree with you that this is not possible normally but this is the case and I do not see what is wrong in the code.
Size:
Color:
I see it too running that code. I can't remember ever using the AutoStops, and that seems to be where something has gone wrong. We'll have to investigate that.
Size:
Color:
Hi Cone,
Do you have news regarding this issue ?
Size:
Color:
I'm looking at it. Don't like what I see. Need more time for troubleshooting. Thanks for bringing it up again ;)
fyi,
The results seem okay if you use "Fixed Bars" for Data Range.
- edit -
Actually I'm mistaken (thankfully). The problem seems to occur only when more than approximately 2300 bars are loaded. Visa (V) has about that number of bars... so let's see where that leads us... Indeed, removing V solves it for the test range.
Size:
Color:
Here goes.. First I want to change a couple items in ApplyAutoStops() as follows:
CODE:
Please log in to see this code.
The first change should avoid errors if more than one position is exited on the same bar.
The second change is a "more accurate" time-based exit. The problem is that the current version will give you the same exit if you put in 1 OR 2 bars for the time based exit! I think D. Aronow coded it as Bar + 1 - p.EntryBar so that it would match the number of "Bars Held" that Wealth-Lab reports in the Performance report; basically Wealth-Lab counts the trade bar in order to make the raw profit data more pessimistic. In other words, if you BuyAtMarket today and SellAtMarket tomorrow, even though you held the position for 24 hrs, Wealth-Lab will report 2 bars held.
Note! After this change, users of the auto stop time-based exit will need to increase the time out by 1 bar to match previous results.
That's the easy part.
The hard part is that there appears to be a Wealth-Lab synchronization issue with trading "DataSetSymbols" when the starting dates of the symbols' series are not the same, provided that some symbols are traded before the start dates of other symbols. So the workarounds at the moment are to:
1. Add a synchronization loop before trading begins.
CODE:
Please log in to see this code.
If this doesn't solve it entirely, it seems to at least help reduce the number of erroneous trades.
2. Another solution is to start trading after the start of the shortest series. (Inherently this does the same sync as before.)
CODE:
Please log in to see this code.
3. Or, simply remove the symbols with the "short series" from the DataSet.
Size:
Color:
Thank you Cone for sharing your investigation. If I understand correctly, the last issue that you have to solve comes with the "synchronization". I think this is not really acceptable if we have to "remove shortly series" to bypass the problem.
What about the possibility to add "virtual bars" with AddCalendarDays ? I don't know if this can work. Maybe someone can find another quick-win ?
Do you know when we will have a new maintenance version ?.The last one has more than 1 year now.
Size:
Color:
Hi Cone,
Do you have news on this issue ?
Are you going to publish a fix for the community components library ?
Size:
Color:
QUOTE:
Are you going to publish a fix for the community components library ?
Published. Thanks Robert. Alexandre, please update the extension.
Size:
Color:
Thank you very much. I will test it.
Size:
Color:
Hi Eugene and Cone,
I use the script in the post #8 with the new version of the Community Components to see if the problem is over.
Except if I have done somethings wrong or haven't understand somethings, I see somethings which look like not correct.
As you will see in my screenshot, the trades table report the end date is the same as the entry date with a held period equal to 6.
Can you help me ?
Size:
Color:
Alexandre,
The fix to AutoStops in C.Components we released last month has nothing to do with the Wealth-Lab synchronization issue that Cone discovered in post #12 with workarounds that alleviate it to some extent (not completely as you know). Unless Robert has some breaking news, I'm not aware of any plans to fix it.
Consider it a deferred issue.
Size:
Color: