Sebastian,
Unfortantely, this discussion has created the wrong impression of a discrepancy between the Wealth-Lab-generated
EquityCurve and "equity" value in PosSizers. This is not the case.
The class I created to work around the absense of equity curve interaction in Version 5/6 essentially is a reverse engineering of what Wealth-Lab does internally. Discrepancies with the native
EquityCurve may exist due to solution's hackish nature, so it's not really a support issue. The open source code is free, so you're welcome to troubleshoot and contribute to make it more robust.
P.S. Your example code has to be improved:
1. The dummy class should inherit from
WealthScript rather than
Test:
CODE:
Please log in to see this code.
2. In Wealth-Lab, trading orders should not be issued for the dates exceeding
bar+1. Therefore I will not consider
obsDate greater than 0 a use case.
3.1. An even margin factor may still not be enough: it's the odd part that makes the difference e.g. 1.05. Ideally, your test should be performed in Raw Profit mode.
3.2. Alternatively, you should have used "Use Worst Trades in Portfolio Simulation" or assigned a fixed Position.Priority value.
4. For the reason above, it's theoretically possible for
LastPosition to error out so I'd use this instead:
CODE:
Please log in to see this code.
Otherwise, there may exist TWO sets of trades: one processed by Wealth-Lab natively (i.e. Test.Execute) and another one in Donor2.Execute. A discrepancy in EquityCurve in this case is guaranteed.
Using the revamped code below I get absolutely IDENTICAL ending value of the EquityCurve, given Raw Profit mode, no commissions, no slippage, "Use Worst Trades..." and NO other options enabled in Preferences:
CODE:
Please log in to see this code.
It doesn't mean that the equity interaction technique doesn't have something to be improved, though. I'll put a note on my todo list to give it another test in the future.