Dear forum members,
I have been back-testing a strategy I’ve been working on and I’ve used the exact same code for the ProOrder as I have in my indicator.
However, when I compare the trades with my indicator, I can clearly see inconsistencies here and there. They are not big, but they fail entries or create entries that should not have occured in my indicators. I can follow the problem by using Graph and comparing the outcome of the different parts of the back-test parameters with my indicators. As mentioned, they are identical in code.
I have set the DEFPARAMPRELOADBARS = 0
This is to make sure that the code in the backtest doesn’t preload any bars. I understand that the indicator shouldn’t preload either – at least it doesn’t look like it.
Any idea why I get this inconsistency?
Thanks
What indicator please? What is the maximal period used in its calculation? Any picture of that difference you get?
Its more or less impossible to help/answer without more context.
Please show code if possible so we can test it, or at least show indicator code and or photos of the failed/missed entries with more explanation.
99% of the time i experience this, its my own fault and after posting in this forum ive been corrected. Feelsgoodman.jpeg
Hi,
I looked at my code for hours till my eyes were bleeding early this morning. It’s a complex code that takes a lot of values at the first bars, and this affects everything, so I did a short test and found there IS A DIFFERENCE between indicators and back-testing. Namely – 1 bar difference.
I have intentionally put in PreloadBars = 0 as I thought this was messing with my code. No difference. So I put a conditional BarIndex entry and found the culprit.
Have a look:
__________________________________________________________________
IF BarIndex > 14 THEN
ATR = AverageTrueRange[14](CLOSE)
ENDIF
RETURN ATR
__________________________________________________________________
// Definition of code parameters
DEFPARAM CumulateOrders = False // Cumulating positions deactivated
DEFPARAM PRELOADBARS = 0
IF BarIndex > 14 THEN
ATR = AverageTrueRange[14](CLOSE)
Trange = TR(CLOSE)
ENDIF
IF Trange > ATR THEN
BUY 1 CONTRACT AT MARKET
ENDIF
IF Trange < ATR THEN
SELL AT MARKET
ENDIF
GRAPH ATR
__________________________________________________________________
Compare the SNAFU indicator with FUBAR graph output.
If I change the BarIndex > 13 in the Indicator SNAFU – then it all works out the same. But if I leave it at 14 on both, – I get one bar displacement. That means that my indicator would not show me the same exit / entry as I would expect in the ProOrder FUBAR at the early bars.
I take it that the 0(zero) bar in BarIndex for indicator SNAFU is differently accounted for when relating to ProOrder back-test and that puts the whole calculation of bars one step later in indicator.
Question is how this affects strategies relying on settings at the first bars? Everything will be skewed as the count of Bars is messed up. Maybe averages will even out over time, but for me counting close and open and relating to these, it is completely out of sync! I get totally different appearances on Indicator and ProOrder.
What platform version? Did you try to remove (close) at the end of the ATR instruction?, if not please try.
Hi,
I tried removing CLOSE command without success. I’m running on 10.3
I can confirm this is a discrepancy solely based on bars. BarIndex(0) is counted in the indicator as a bar, which it is not in Back-Testing as it is an incomplete bar I guess. So those are totally out of sync.
This makes back-testing very odd when analysing the outcome! Unfortunately I see this as a bug! Especially as they are time-lined so that you should be able to follow what happens in the back-test versus your price AND indicators. And if you use the same indicator as a trigger for the action – you would expect the same outcome, which is extremely perplexing when you define PRELOADBARS = 0. I’m coding a ZeroBarCorrection of + 1 in everything that could cause this problem for now. It solves the problem for now…
Surprised no one has reacted on this until now…
Not sure if it is fixed in version 11.
Regarding version 11…I can’t do back-testing as I have no IG connection… since it is not supported by IG… which… by the looks of it… won’t be happening for another… year???
Your code above:
IF BarIndex > 14 THEN
ATR = AverageTrueRange[14](CLOSE)
Trange = TR(CLOSE)
ENDIF
will calculate ATR when BarIndex = 15 (or greater), so it will scan the last 14 bars (2 through 15) to make the calculations, while replacing 14 with 13 will calculate it on bars 1-14.
BarIndex starts from 0, so to calculate 14 bars starting from bars 0 you should replace > 14 with > 12.
Hi,
I see your point. However the snippet of code is not part of the indicator, it is merely to show the inconsistency. My first line is actually an equaliser formula to be able to use ONCE command for variables.
For simplicity, in my code I use ATRperiod as a value (14)
ATRperiod = 14
IF BarIndex = ATRperiod THEN
ATR = AverageTrueRange[ATRperiod](CLOSE)
ENDIF
And in the ProOrder I use
BarZeroCorrection = 1
ATRperiod = 14
IF BarIndex + BarZeroCorrection = ATRperiod THEN
ATR = AverageTrueRange[ATRperiod](CLOSE)
ENDIF
I find this to be easier to address when reading the code as the problem is that BarIndex[0] that causes the problem!
Try not using ONCE in your indicator.
Well… this specific indicator requires it 🙂
Replace ONCE with:
If barindex = 0 then
MyVariable = ...
Endif
