Extended backtesting mode needs tweaking

Questions about MultiCharts and user contributed studies.
wilkinsw
Posts: 662
Joined: 21 Apr 2013
Has thanked: 154 times
Been thanked: 104 times

Extended backtesting mode needs tweaking

Postby wilkinsw » 09 Sep 2015

extended backtest too harsh.PNG
(27.63 KiB) Downloaded 525 times
Tweaking is an understatement. Extended backtesting needs overhauling (please prove me wrong)! I'm assuming the point of extended backtesting is to enhance the accuracy of fill assumptions by referencing bid/ask data.

There are three issues that I've identified that will significantly improve modelling assumptions of extended backtests. I think MC is a great product and I'm sure it is obvious to most that modelling assumptions are the cornerstone of effective trading system development.

I invite feedback from MC and criticism from MC users.

The first issue:

If bid>=sell limit price then sell order = filled.

My issue is that additionally, sell order = filled when last traded price >= sell limit price (depending on backtest setting).

This second condition needs adding to the extended backtesting engine.

I've attached a screenshot displaying this example
Last edited by wilkinsw on 09 Sep 2015, edited 1 time in total.

wilkinsw
Posts: 662
Joined: 21 Apr 2013
Has thanked: 154 times
Been thanked: 104 times

Re: Extended backtesting mode needs tweaking

Postby wilkinsw » 09 Sep 2015

The second issue I found, when using tick charts, occurs in the event of a large single matching event (a large aggressor order going through or a cascade of stops being triggered), aka a "blip".

Because of the way market data is handled (FIX/FAST, MDP3.0 messaging etc), info on how the book is left will follow the cascade of matching event messages. So, when a large event goes through, on a tick chart, this means lots of ticks with no bid/ask updates for a long time (until the matching cascade has finished).

Do note that a "tick" is not necessarily a single trade. A tick is a match against a resting limit order. Hence a blip is diplayed as multiple ticks.

The issue with MC in extended backtesting mode is that should an entry condition = true in the middle of a blip, then MC will reference the last known bid/ask to determine if and where the fill occured. This, of course, is wrong. MC should wait for the next update of the bid ask, following a entry signal=true event.

I've attached an illustration.....
Blip wto latency incorrect.png
(40.13 KiB) Downloaded 511 times

wilkinsw
Posts: 662
Joined: 21 Apr 2013
Has thanked: 154 times
Been thanked: 104 times

Re: Extended backtesting mode needs tweaking

Postby wilkinsw » 09 Sep 2015

It would make ones life easier if MC can address both of these incorrect modelling assumptions.

There is a workaround that I use for handling the "price improvement / false fill on blip" event. I also advise anyone use this when backtesting on tick data.

Simply put, you need to reference all variables and data values from t-latency using the following as an example (please note the variables here could be replaced with anything of importance to the developer, "latency" and "refbb" are the key components):

Code: Select all

//////////////////
////lagging (latency driven) variables
inputs:latency(0.050);
vars:tl1(0),tl2(0),refbb(0),cl1(0);

for counter=0 to maxbarsback begin
tl1=((datetime-datetime[counter])/0.0000115740740740);
tl2=round(tl1,3);
if tl2>=latency then break;
end;
refbb=counter;

lagupb3[sens]=upb3[sens][refbb];
lagupwh[sens]=upwh[sens][refbb];
lagavgUW[sens]=avgUW[sens][refbb];
lagdpb3[sens]=dpb3[sens][refbb];
lagdnwh[sens]=downwh[sens][refbb];
lagavgDW[sens]=avgDW[sens][refbb];
cl1=close[refbb];
///////////////////////////
Therefore, instead of buying when x=true, you are buying when x[latency]=true with variables[latency]. Then waiting for entrytime+latency until placing position management orders [latency adjusted too].

I've attached the outcome when this is done. Compare is to my previous attachment......
Capture blip with latency.PNG
(38.09 KiB) Downloaded 509 times
Last edited by wilkinsw on 09 Sep 2015, edited 2 times in total.

wilkinsw
Posts: 662
Joined: 21 Apr 2013
Has thanked: 154 times
Been thanked: 104 times

Re: Extended backtesting mode needs tweaking

Postby wilkinsw » 09 Sep 2015

The third issue is the triggering and filling of stops.

I simply don't understand the behavior in extended backtesting.

It should be (as I'm sure is obvious):

If last traded = sell stop trigger price then fill at bid (ideally wait for an updated bid first!)

What seems to be happening instead is that MC waits for..

If ask<=sell stop trigger then [when last traded price updates] fill at bid

Please see my attachments for further illustration.........
stop trigger 1.png
(29.32 KiB) Downloaded 511 times
stop trigger 2.png
(29.46 KiB) Downloaded 522 times
I hope MC agree that these are some fundamental flaws. Please challenge me on anything you think I might have wrong.

wilkinsw
Posts: 662
Joined: 21 Apr 2013
Has thanked: 154 times
Been thanked: 104 times

Re: Extended backtesting mode needs tweaking

Postby wilkinsw » 15 Oct 2015

Has this been acknowledged?


Return to “MultiCharts”