Closed femtotrader closed 7 months ago
Hi Femtotrader, Not sure if you still monitor this - I was having the same question.
One thing I could think of is to use a sort of backtest-loop-counter and prevent the fill event from being executed in the same loop iteration. So basically, the fill event would stay in the queue until the next iteration (with the next executable price). Do you think this is viable?
The need for a kind of limit-order still exists even with this fix (I guess that's where you're going with the "or not" part).
Dirk
Hi @DirkFR ,
This issue doesn't deals with limit-order (but as you said previously "the need for a kind of limit-order still exists")
To be more clear about the "or not" part of my question you might have a look at http://www.metatrader5.com/en/terminal/help/performing_deals and https://www.mql5.com/en/docs/constants/environment_state/marketinfoconstants#enum_symbol_trade_execution and see differences between "Market execution" and "Instant execution" (with Deviation)
I think an other queue (belonging to execution handler) is necessary (maybe a priority queue) to perform Market execution or instant execution.
Current behaviour of this backtester looks like "Request Execution Mode".
femto
Hello,
Reading the code I was pretty sure
FillEvent
doesn't have correct timestamp/price In fact a strategy generate aSignalEvent
which is sized, and risk measured so we have an OrderEvent (market order) in events queue.There is pretty no chance that this order will be executed at exactly same price than what your strategy "saw" when generating this
SignalEvent
.To my understanding, order should be executed at next price, next timestamp.
Here is an example strategy to show this behavior:
and
execution_handler/ib_simulated.py
was modified according:Here is
data/GOOG.csv
and strategy output
We clearly see that order is executed at 2016-02-01 00:00:05.215000 with price 6835600099 In fact, it should be executed (or not) only at 00:00:06.509000 with price 6835600200
Why I'm saying "or not"... because you should be able to set a maximum allowed slippage.
If execution price is too far from expected price, order won't be executed.
What is your opinion ?
Do you have any idea to "fix" it ?
Maybe we should make an other kind of execution handler with such behavior ?
Kind regards