I believe I may have found an issue with TradeHistory CSV import when a position has multiple partial exits on the same date.
I reduced the behavior to this minimal three-row CSV:
2001-05-14,BUY,TDS,97,103
2001-05-17,SELL,TDS,48,105.9
2001-05-17,SELL,TDS,49,105.81682
The first transaction opens a 97-share long position.
The two transactions on May 17 sell 48 and 49 shares respectively, so I would expect the position to be completely closed:
48 + 49 = 97
However, after importing this into WealthLab, TradeHistory shows two closed trades of 48 shares and leaves a 1-share TDS position open.
In other words, the resulting positions appear to be equivalent to:
48 shares closed
48 shares closed
1 share still open
rather than the expected:
48 shares closed
49 shares closed
0 shares open
I originally encountered this while importing a much larger generated TradeHistory. To eliminate my generating application as a possible cause, I then created the above three-line file manually and imported it independently. It reproduces the same result.
Could you let me know whether you can reproduce this too? If so, this appears to be an issue in how the second partial exit is being matched or allocated.
I reduced the behavior to this minimal three-row CSV:
2001-05-14,BUY,TDS,97,103
2001-05-17,SELL,TDS,48,105.9
2001-05-17,SELL,TDS,49,105.81682
The first transaction opens a 97-share long position.
The two transactions on May 17 sell 48 and 49 shares respectively, so I would expect the position to be completely closed:
48 + 49 = 97
However, after importing this into WealthLab, TradeHistory shows two closed trades of 48 shares and leaves a 1-share TDS position open.
In other words, the resulting positions appear to be equivalent to:
48 shares closed
48 shares closed
1 share still open
rather than the expected:
48 shares closed
49 shares closed
0 shares open
I originally encountered this while importing a much larger generated TradeHistory. To eliminate my generating application as a possible cause, I then created the above three-line file manually and imported it independently. It reproduces the same result.
Could you let me know whether you can reproduce this too? If so, this appears to be an issue in how the second partial exit is being matched or allocated.
Rename
Are you seeing 2 separate transactions in the Positions list? I think you should, but I am not and don't know why!
Since TDS has 2 splits after those trades, I created a MM record to see the number of shares as a floating point number. With or without an Event Provider for splits, I get the same result - 1 round trip with the exit at the second price.
Here's my Positions list for each of those runs - same Trade file, but just enabling/disabling Yahoo! Splits.
Since TDS has 2 splits after those trades, I created a MM record to see the number of shares as a floating point number. With or without an Event Provider for splits, I get the same result - 1 round trip with the exit at the second price.
Here's my Positions list for each of those runs - same Trade file, but just enabling/disabling Yahoo! Splits.
Thanks. I'm getting a different result from you, which may be significant.
I'm using IQFeed as my data source. With the three-line trade file I posted, WealthLab gives me three positions:
Long TDS 1 5/14/2001 103 Open
Long TDS 48 5/14/2001 103 5/17/2001 105.90
Long TDS 48 5/14/2001 103 5/17/2001 105.81682
So in my case WealthLab correctly recognizes both exit prices, but it assigns 48 shares to each exit and leaves 1 share open.
The original trade records are:
2001-05-14,BUY,TDS,97,103
2001-05-17,SELL,TDS,48,105.9
2001-05-17,SELL,TDS,49,105.81682
I would therefore expect two closed Positions of 48 and 49 shares, with no position remaining open.
Your result seems different again: if you're getting one 97-share round trip at the second exit price, it appears that the first 48-share execution at 105.90 isn't represented in the resulting Position.
I don't think the later TDS splits should affect either exit since both occur on 5/17/2001, but perhaps the difference between our data sources helps explain why we're getting different results.
I'm using IQFeed as my data source. With the three-line trade file I posted, WealthLab gives me three positions:
Long TDS 1 5/14/2001 103 Open
Long TDS 48 5/14/2001 103 5/17/2001 105.90
Long TDS 48 5/14/2001 103 5/17/2001 105.81682
So in my case WealthLab correctly recognizes both exit prices, but it assigns 48 shares to each exit and leaves 1 share open.
The original trade records are:
2001-05-14,BUY,TDS,97,103
2001-05-17,SELL,TDS,48,105.9
2001-05-17,SELL,TDS,49,105.81682
I would therefore expect two closed Positions of 48 and 49 shares, with no position remaining open.
Your result seems different again: if you're getting one 97-share round trip at the second exit price, it appears that the first 48-share execution at 105.90 isn't represented in the resulting Position.
I don't think the later TDS splits should affect either exit since both occur on 5/17/2001, but perhaps the difference between our data sources helps explain why we're getting different results.
The difference isn't the DataSource - it's a Backtester function and we'll get to the bottom of it. (The number of shares and prices, however, would be affected by Splits for a selected Event Provider, as shown above.)
Meanwhile, humour me by right clicking the Backtester's Positions list and pasting the result to make sure there are no decimals in the share Quantities. Only whole numbers are displayed for stock shares unless you create Market Manager to adjust the 'Qty Decimals'.
Meanwhile, humour me by right clicking the Backtester's Positions list and pasting the result to make sure there are no decimals in the share Quantities. Only whole numbers are displayed for stock shares unless you create Market Manager to adjust the 'Qty Decimals'.
I'm still not sure why you're seeing what you're seeing (which WL build are you using?), but we found that my scenario was caused by a side effect of another change for strategy related processing in WL9.
Give it another try when Build 7 becomes available. It looks good now - thanks for spotting it!
Give it another try when Build 7 becomes available. It looks good now - thanks for spotting it!
I am on WL8-172, I'm afraid I need to be controlled moving to WL9.
That's even more bizarre.. we found a problem in WL9 on your report about an issue in WL8 that we can't duplicate there!
Your Response
Post
Edit Post
Login is required