Translating MQL4 ibands() to Matlab

Question

I'm trying to translate an indicator from MQL4 (Metatrader language) to Matlab. The Bollinger bands code is as follows:

for(int i=Bars;i>=0;i--)
{
    BANDS=iBands(Symbol(),0,20,2,1,0,1,i+1);
}

the iBands() documentation lists the 8 inputs as:

symbol 
timeframe   
period    
deviation   
bands_shift 
applied_price   
mode     
shift

I understand all these except bands_shift and shift. Question: If i = Bars is the entire range of the data, why does the i+1 not create an out of range error? As far as I can tell, this is code for a 20 period, 2 standard deviation Bollinger band. For a given time interval, are the associated Bollinger band values the values calculated for the previous time interval (hence the 1 after the fourth comma)? What does the i+1 do then? Given this code, how would I implement in matlab? My attempt, using this moving standard deviation and this moving average:

moving_average = movemean(EURUSD_closes(1:end-1),20); %end-1 in order to shift by 1 
moving_average = [NaN; moving_average]; %adding NaN to make BANDS the length of price

moving_std = movestd(EURUSD_closes(1:end-1),20,'backward');
moving_std = [NaN; moving_std1];

BANDS = moving_average + 2*moving_std;

I don't think this gives the same output as the MQL4 code. Any hints would definitely be appreciated!

Answer 1

With my little knowledge of Bollinger bands, it seems like you might have an implementation issue. Have you tried the output of Bollinger function in MATLAB?

Bollinger bands may have been implemented differently for edge cases where the window size is less than 20. You might have to contact the MQL4 authors to check on the formulae used. I noticed a difference when I implemented in Python and the indicator seen in Google finance. Nevertheless, if you have implemented correctly, the values where the window size is of 20, you will see the same values.

Unless you are very sure of the FEX code, you should use std and mean for implementation.

Answer 2

How to understand iBars+1 and a "Missing" Out of Range Error

MQL4 works in a "reversed-TimeDOMAIN-indexing" space. Thus the iBar shows the "depth" of historical TimeSeriesDataSET, while the most recent (live) bar has an index of [0].

Always [0].

This means, that for a calculation of any technical indicator, the coder must arrange the processing in this manner.

This also means, that for any new bar, the internal representation of the data-storage-layer has to somehow "shift" all DataCELLs by one to the "left" ( backwards in a TimeDOMAIN direction towards History ) to make a "space" for a new bar having still index of [0] ( a Now moment in a TimeDOMAIN ).

While "physically" moving all the current "depth" of the DataSTORE would be an absolute vaste of resources ( both time, CPU, .. ), the data-storage-layer works smarter, adjusts the indexing-head on each new bar event plus uses some form of elastic DataSTORE capacity planning/re-size on-demand, so as to minimise the mem-alloc(s) during the continuous growth of the DataSTORE.

This means, that testing for an Out of Range Error does not have support in user-code namespace of the MQL4 language.

How to understand bands_shift and shift.

Calling iBands() has to state for which Bar one asks the function to calculate a result.

shift provides input for this. The index obeys the rules above.

Once the Bollinger Bands calculations are done, one may wish to offset the curves by some amount of Bars -- transposing the graph in TimeDOMAIN { +N << left | -N >> right } -- so that the visualised graphics meets one's expectations or pleasure.

bands_shift provides input for this graph ad-hoc shifting.

Also note, that the observed differences between Google, Y!Finance, MATLAB and MQL4 graphs simply have to appear and account for additional ( not known ) details one can hardly decode from the lines just shown on the screen.

applied_price := { PRICE_CLOSE | ... | ..._TYPICAL | ..._WEIGHTED } provides an input for selecting appropriate type of price entering the Bollinger calculus.

mode := { MODE_UPPER | MODE_MAIN | MODE_LOWER } provides input for receiving either an { upper_band | Bollinger Bands' axis | lower_band } PriceDOMAIN value. Thus a "Lazy approach" is to call the iBands() thrice to get the tree-line-Bollinger, or many times for a spectrum-coloured Bollinger Band heat-maps.