Feature Request: more realism for Limit order execution

To aid realism to backtesting fills of limit orders - be it from Entry or TakeProfit - it would be very useful to be able to specify the extent of "overshoot" over the limit price.

This can be a separate Fill (or Slippage) mode, where
e.g. setting Fill= -0.3*PIP will fill limit order when trade price goes beyond limit price by 0.3 pips.

Thank you in advance.

That makes sense. Will be implemented in a future version.

jcl, can you pls elaborate on what you mean by a "flat fill price offset"?

>>Penalty
Alternative simulated slippage in counter currency units (default = 0), used in [Test] mode for entering and exiting trades and for entry and exit limits. Overrides Slippage and the limit fill algorithm (see Fill) when nonzero. Has no effect in [Train] mode. Orders are filled at the current price with Penalty either added or subtracted dependent on trade direction. <<

It is not the same as you proposed, but can be used for the same purpose.

Hmmm...do i understand correctly that Penalty=-0.5*PIP will make fill price more advantageous then that set by Entry limit ? (and will allow setting a fixed 'slippage' in pips, rather than seconds, for stops?)

If so, then - for limits - this works counter to the 'realism' objective:
a) filling limits at better prices is a rare 'bonus' not to be counted on in development/evaluation and
b) the order will still fill (!)- even though at possibly a worse price...while it might not at all in reality...Which was the whole point of asking for a 'safety margin' on fill/no fill in testing...and training such a system.

What would be the way to use Penalty for such purpose?

It fills at worse prices. Which is why it's named 'penalty'. Otherwise we had called it 'bonus'.

If you just want an order not to fill at Entry, you need no extra variable. Simply add something to Entry.

This will simulate stop fills more realistically...but limits?

This would not work you optimize an Entry limit. A "safety margin" would guard against picking the exact highs/lows.

Can negative Penalty be made to work the way I originally suggested? (in Train)

I understand your explanations so that you want to place a long order at $100 limit, but it should be triggered not at $100, but at $99, but fill still at $100. That would be Entry = -99, Penalty = 1. Otherwise please explain what you want to achieve and to what purpose, preferably with an example.

Say, I want to see if entering at limit can help squeeze some extra performance.

The first easy step is Entry = - optimize(1, 1, 10, 1);

Say, 10% of trades have a MAE of 7 (sharp) and 10% - 7.1-7.5

Any combination of Entry and Penalty will result in the EXACT price level, and so the optimization will find Entry=-7 as the optimum (but will apply a Penalty to results).

But such trades entered at exact highs/lows - most probably responsible for a disproportionately big share of profit - are unrealistic.

So, it would be very useful to specify the extent of MINIMUM "overshoot" over the limit price (either from Entry or TakeProfit), meaning fills happen when price goes beyond limit price by AT LEAST X.

With Penalty= - 0.6, the optimum Entry in this example will be found in Train as -6.

Primary utility of such feature is in Train mode. (In Test - any desired limit entry can be simulated as you suggested).

When 10% trades have MAE 7, the optimization result is unknown. When we assume that 100% trades have MAE of exactly 7, the optimized Entry is -7. The trade would then be filled at current price - 7 + Penalty. Since Penalty applies to all trades, it has no effect on the optimization. You would then set the live order limit at Entry + Penalty, because that is the fill price that you get from the broker. The live result will then match the backtest. The specified Penalty is your overshoot.

I gave an example of 10% and 10% because of the '20/80' rule. Results of <20% of trades will drive the optimization results...

The difference between what you suggest and I is in 'strictness' of the overshoot.

If it exactly Entry+Penalty, then the optimization will most likely overfit...If it is '<=Entry+overshoot', it is less likely to be so.

Again, that is mostly needed for efficient discovery/prototyping, with a piece of mind that it is sufficiently realistic. (handling orders in live is the next step/ different discussion)

Would really appreciate if negative Penalty would work as described for Entry and TakeProfit.

It will overfit in both cases, since they are technically equivalent. They produce the same trades. The only difference is an offset to Entry.

The overfitting is not due to Penalty, but because you're likely training on random noise when you optimize Entry in this way.