Reason why it is needed:
We backtest gaps and need to simulate full profit caused by gap.
As Profit order is of type Limit, NT8 simulates conservative filling of the order,
instead of real bigger profit, that would be caused by big gap.
Example:
- Enter position 5 minutes before end of the week and set profit order to 10 ticks.
- After weekend, market opens with 40 ticks gap, which would cause 40+ ticks profit.
- But NT8 default fill strategy simulates conservative filling of old profit = 10 ticks, which is completely wrong. Real profit should be 40+ ticks.
I completely agree, that this default handling of Limit order fills is rational and good as a default behavior. I like it as it is.
But we developers should not be stuck, by inability to alter it. This default conservative handling is not one for all solution. There are many cases (like the one above), where we really need to alter this default conservative handling of fills, to correctly simulate situations, we need to backtest.
- We need to expose FillType and be able to create our own FillTypes for all strategies, the default behavior is not usable.
- Valid cases are, when the strategy results in incorrect fills (too much conservative), that do not reflect reality. Results of such strategies implemented in NT8 using default FillType are completely skewed and invalid.
So allow for implementation of custom FillType(s) please.
NT8 is about progress, evolution and improving old concepts to new more professional level.
so don't hesitate to make FillType accessible, because it requires experienced/advanced coding.
We need powerful framework, the enables us to do, what we need in daily practice.
As NT8 gets more adoption (after final release of NT8), rising community of developers find out anyway, that without custom FillType, they are restricted and completely unable to implement advanced things, that they could do in NT7.
Remember and this is important:
- The default fill strategy is not correct for every strategy and it is definitely not one-for-all solution.
- It just rational default = good point to start with. Tthere are many valid cases, where it does simulates real fills correctly and we need to alter this default filling strategy.
If there is clear, rational and practical need for implementation of custom FillType, it should be accessible.
Comment