I am starting to write this article in the idea that it might become useful in a not too far time horizon. I have been thinking at this for some time. The autotuning is an idea that is out there for some while, however the extreme complexity of retail trading systems approach made it quite inapplicable. However, HFT trading systems are generally simple, and quite similar rules are applied to hundreds of equities, in a parametrized fashion. Thus, if rules are simple and can be written in “when this, do that , resulting this” instead of maze-like logics of retail systems, then a set of optimal statistics on the entry data (spanning over an array of quotes, orderbook data and so on) is the premise for simple operations like quoting, getting filled, taking profit or stop loss in just a few ticks away. As seen in the previous Progress Apama article, these algorithms are highly unstable, therefore there is a constant run for newer algorithms.

Now you may ask, why would we attempt autotuning of trading systems if the institutionals do not (at least on the HFT level). Thing is, some of their algos are so fast that they might not even have time enough to record the data in a database, so automatic tuning, that requires extra analysis, might be a complete waste of time, with a too small improvement brought to the algos compared to the extra latency that is forming up. What will be coming in these articles has therefore an experimental nature and doesn’t have to be taken as a solution, rather an attempt – I cannot tell for sure if there is any point in attempting to find, with regular statistics, recurring parameters of a stochastic process.

So, let’s presume that an array of parameters (such as individual volatilities, moving averages, executions volume, etc.), is to be fed to a database or to an inner storing array. We have to take into account the fact that a trading signal may exist permanently, at every tick. Supposing the volume to be constant, then same signal can be wired into two actions: either buy or sell. Each signal will therefore have two results, one for buying, one for selling. We could however create separate rules for selling.

For instance, a signal comprised of a volatility and the distance between mid quote and mid quotes moving average comes with: 0.03 stddev & 2 ticks. To twist it a bit, we introduce quoting, and we note 0 for no fill. Wired into a buy with a 3 tick take profit and 2 tick stop loss, at a given time, makes 2 ticks profit, wired into a sell it is not filled. So the buys database will be added a (0.03 ; 2 ; 2) and the sells (0.03 ; 2 ; 0).

And now the things become interesting. At the end, after the data is gathered for a mass of signals that make up the “big number” for the statistics, we have to look thru the database. First, a simple watch will group the database by action and result. In this case, we have six final states:

1. BUY: quote, get filled, take profit (BQFT)
2. BUY: quote, get filled, stop loss (BQFS)
3. BUY: quote, don’t get filled, cancel order (BQC)
4. SELL: quote, get filled, take profit (SQFT)
5. SELL: quote, get filled, stop loss (SQFS)
6. SELL: quote, don’t get filled, cancel order (SQC)

So we have six cases. Analysing BUY with quote, get filled, take profit, is just one of the six states and will comprise a large part of data, the same as the other states. The purpose of the statistical analysis is to have a statistic prepaired per each case. For instance, our case should look, in the end, like:

0.03, 2 : 45% BQFT, 35% BQSL, 20% BQC ; 30% SQFT, 30% SQSL, 40% SQC

After the intial mass of signals along with results is collected, statistics have to be deployed for each combination of the parameters. Having real numbers as parameters, with lots of digits , will lead to the fact that you may have actually a number of cases equal to the number of signals that were the input, rendering statistics impossible. So, there has to be applied some data aggregation. For instance, for each parameter set, can be calculated the quartiles then the number of bins with the Freedman-Diaconis formula (this is an example, other methods can be applied). This will yield up a different number of bins for each of the parameters. Then a new array will be created, where each case will have a sticker denoting its number of bins. For instance the 0.03 stddev is labeled as “Bin 1″ on the stddev scale and the 2 tick distance is labeled as “Bin 2″ on the tick distance scale. The total number of cases may be smaller or equal than the product of bins count per each criteria. If you have 3 criterias and 10 bins each, that may be even 1000 number of cases. More likely, a core number of cases will have a lot of situations recorded, while others will barely have one situation recorded. However, the more platykurtic the repartition of situations per cases, the more enforced the need for a “bigger number” of situations. After applying the statistics, our database statistics will look like:

Bin 1, Bin 2 : 45% BQFT, 35% BQSL, 20% BQC ; 30% SQFT, 30% SQSL, 40% SQC

What is important is that relevant statistics is to be extracted. If this is the current case, what would be the trading decision? Go for a buy with a chance of take profit in 45% of the situations this case appears? Only that it has to stand to 35% stop losses… Because on the sell side it’s even worse, with stop losses situations roughly equal to take profit ones. This case has to be decided as a buy case, although with reserves. Unless the profits are relevant enough, there is no decision to be taken. Nevertheless, it is mandatory for the algo to have a decision module that picks only relevant cases for trading. But how fast can the machine be, because after the initial data is gathered, each new signal, (that can be even a new tick, in a HFT-like algo), will trigger a massive recalculation of bin sizes on the entire database, to update the statistics, and at the same time to allow the delivering and execution of the trading decision in real time?

Remember my article about the CEP engine. The CEP is visioned there as a recognition – trigger module, but what if the CEP is first used as a recording device ? What if the CEP is wired to the statistics engine? How much latency would this add to the calculus? Can we still talk about real time?

If there wouldn’t be that CEP abbreviation there you’d probably ask how that something inherently complex could become simple. Thing is, everything starts by being simple at first then evolving to something more complicated.

Even if you might have read my Progress Apama article, I remind you here the definition given by Dan Hubscher to CEP : “the ability to relate two or more events, even if these events occur in a span of time, and then determining meaning from that relationship immediately, such as detecting a trading signal, or an alpha-generating profit opportunity”.

So, given that events have to be related, within a time constraint, there must be an event queue, which stores individual events , as they are being received. Sure, storing is not made ad infinitum, in an ever increasing queue ; the queue size has to be dynamic, but it’s length in time should not exceed a predetermined amount of time, say 5 minutes. This is why a CEP engine, that is mainly targetted for HFT and Level II trading, doesn’t have to mixed with Level I trading signals, because these span on a way higher amount of time, lots of minutes to hours or even more, making the event stack not only to grow to an unmanageable size, but also to slow down the engine speed.

The covered amount of time is the first limitation of the engine.

Second, is the link between simple events. Simple events are not fully independent, as the Progress Apama webinar slide might show. For instance, you are considering a cross of higher Bollinger Band as an event, but also the cross of the lower Bollinger Band. These events are completely opposite. Should both happen, at the time the second happens, the first one must elliminated from the queue, as you see in the scheme below that event 4 is deleted. There are two paths that may be chosen, either opposite events are removed from the event queue after some time – which is diffcult to determine, or before final validation of a complex event there are searched opposite simple events coming after the ones that make up the complex event.

Third, avoiding event redundancy. Bad implementations can cause redundancy, meaningly same event to be reported over and over again. For instance, “MSFT is below 5-minute moving average”. A parenthesis here – I don’t mean the 5 minute chart, rather the moving average of all ticks occurred in last 5 minutes, that’s why I said MetaTrader should have tick data and tick period enabled.When it happens, it is an event. But the next second, at the next tick, it will be reported again, and the engine has to reject it, because it already is in the queue, as there is the case with the orange event from the scheme, which doesn’t even gets a number, because it is rejected from the beginning. Such situations should be avoided from start – the engine mustn’t lose time for redundancy check, otherwise the engine should be able to filter for these events , but it’s better that the event stream is cleaned before.

This is the schematics of the engine. The tick events, or the more complex calculus events originate from an OnChart() event that is triggered by more Tick Event EAs, as they are described in the article Tick events in MQL5: complicated for now, but functional .

The first column is event number in the queue, from the most recent to the oldest. Each simple event, that is linked to the data, has a number allocated to it. The same event, happening on a different instrument, has to be given a different number, so same event sequence making up a complex event will be made up of same simple events but with different identfiers. The engine must know which events are completely opposite, for instance 1 and 3, also which event is allowed to appear multiple times in the queue, because some may be allowed (for instance execution events (the ones beginning with E in the scheme)). All other events will be forbidden from appearing multiple times – but however this should not be done by the engine per se, the one that moves the event queue, rather these must be forbidden from the pre-processing phase.

At the same time, the CEP engine must recognize each complex event knowing all simple event arrangements.
For instance, if a complex event for Microsoft (MSFT) is made of “10 followed by (11 or (12 and 13))” within 3 minutes, then the binder will look for, within 3 minutes: 10, 11 ; 10, 12, 13 ; 10, 13, 12 meaning for all alternate paths. If the same event would mapped for SP500 (^GSPC), given that its sub events will have different numbers, the condition might look like “5 followed by (15 or (16 and 17))”, having the arrangements: 5, 15 ; 5, 16, 17 ; 5, 17, 16. Such arrangements can be given directly to the engine, written directly inside, or generated inside with an algorithm, transforming the binary expression, with the notable difference that “FOLLOWED BY” is a non commutative AND. Because the rules are defined as series of events appearing in a certain order, the negation can’t exist as in a binary expression. It can be implemented only a a interdiction for some events to appear over the entire time constraint or within some sequences, as simple forbidden entries between required events.

You can see that I included in the scheme two bind columns. That is , one simple event can be binded to more than one complex event, because otherwise some rules would never trigger. Complex events would have a separate ID set, that is not to intersect with the simple events ID sets. The engine core will send the complex events to be processed by user in the EventsCallback(), but at the same time, the user could pipeline these events to another CEP engine.

The matching algorithm begins with the construction of the simple events matrix per each complex event. The simple event matrix will contain on each row an arrangement. Because checking is done backward, from the later events to older events, arrangements have to be written in the matrix in a reversed manner. Each complex event will need passing thru the events queue only for as long as the time constraint spans, in a vertical manner : first pass will check events on the first column, and simple events found this way will be pre-binded ; second pass will check the second column only for arrangements that had a pre-bind on the first. When no new pre-binds take place, matching is aborted for that specific complex event. However, to minimize the time needed, each pass will regard all events, before jumping to the next pass. When searches are cancelled for all complex events, algorithm ends.
When an arrangement has all simple-events pre-binded, it’s time to check for negations. First, there will be an entire period check for global negations – events forbidden during entire complex event, then for events forbidden between pre-binded events. When all negations are checked,a final check has to be done to ensure they still abide the time constraint, and only in this case, simple events are binded to the complex event, provided that in the bind array of each simple event this bind is not previously done – to avoid re-binding to same complex event. The resulting complex event is then put in a bind queue and passed to EventsCallback(). Sending events to EventsCallback() must take place after the algo is done, otherwise there might appear recursive engine calls that will not end their execution.For the simple events that are being binded, the current bind array position will be filled with the complex event, the position is then incremented by one.

Here is an example of different complex events in different stages of pre-binding:

For the MSFT event, the engine finds event 12 on the first pass, and pre-binds it on the third arrangement. On the second pass, it finds event 13, and pre-binds it to the second arrangement. It finds 12 too, but it can’t pre-bind it to the second arrangement because it occurred before 13. If on the next pass finds the older 10 event, third arrangement is completed, being no negations there, and if time still abides constraint, provided that complex event 1 was not binded yet, then simple events on the third arrangement are binded to complex event 1, bind counter incremented, event placed in the bind queue. For the ^GSPC event (complex event 2), the engine has completed already the first arrangement. Event 5 does not appear checked for second and third arrangement because events on the previous columns are not checked.

As for the execution events, these are sent by the EnumCallbacks() event of the DealHandler class from the Distinguishing quasi simultaneous fills – class to report last deals article. Simple execution events can also be mapped in more complex execution events because deals have magic numbers and comments, and if you buy two times in row same 1000 stocks, you will know which buy was part of which complex execution event. This is why such events could be treated either seperately or in combination with market events.

We will come with a coding example in a future article.

This is a continuation of our article Intro to Options. Part II : Option valuation and greeks . However, it can be viewed and understood seperately, because it focuses on the programming side.

The option models are exceedingly complicated from the math point of view. The purpose of this article is to present an implementation of the Black-Scholes valuation model, also by introducing virtual methods.

One of the functions that appears over and over again in financial math, also in the Black-Scholes model, is the cummulative distribution function.

The function that describes the bell-shaped form of the distribution is called probability density function. The area that is below it, meaningly the definite integral , is the cummulative distribution function. And for the case with 0 mean and 1 standard deviation, (assuming also no skewness , mezokurtic) this distribution is called normal.

The definite integral, also known as Riemann sum, calculates the area below a function’s graphics by adding infinitezimal rectangles that span below the function and x axis. Obviously, the Riemann calculus procedure is always the same, while the function is something user defined. Both Pascal and C++ allowed function types. A C++ declaration would have looked like this:

typedef  double (*SingleVarFunction) (double) ;
double Riemann(SingleVarFunction pFunc,double a, double b, int divisions)

In this C++ case, the Riemann could have received as parameter any function that received one double as parameter and returned double as result. However, this mechanism does not exist in MQL5.

This is where virtual methods come into play. Objects have properties. Properties that are designed to be public can be accessed from outside the objects, and then methods called again. For instance the user can change the radius of a circle and call the redraw method. But in the case of a Riemann sum what has to be passed as a property value is itself a method. User-defined methods that are called by inherited methods are called virtual methods.

This is the MQL5 implementation for Riemann sum:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

class RiemannSumCalculus
    {
     public:
     virtual double IntegratableFunction(double x)
       {
        return (0.0);
       }     
     double Riemann(double a,double b,uint divisions)
       {
        double sum,swap,stepsize,x;
        long istep;
        if (a>b) 
          {
           swap=a;
           a=b;
           b=swap;
          }
        sum=0.0;
        if (divisions==0)
          divisions=1;
        stepsize=(b-a)/divisions;
        for (istep=1;istep<=divisions;istep++)
           {
            x=a+(istep-0.5)*stepsize;
            sum=sum+IntegratableFunction(x)*stepsize;
           }
        return(sum);
       }
     };

As you see, the IntegratableFunction method is designed as virtual. The function itself does nothing, returns always a zero. Because the function is not made to be used directly. It is just a place holder for user-defined IntegratableFunction(s) that are to be used by the Riemann method.

Next step is to have the Gauss cummulative distribution.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class GaussCummulativeFunction : public RiemannSumCalculus          
  { 
    private: double sigma;  
    public:                                 
    virtual double IntegratableFunction(double x)
       { 
        return( exp((-x*x)/(2*sigma*sigma)) );
       }
    double CummulativeDistribution(double stddev,double l1,double l2,uint divisions)
       {
        sigma=stddev;
        return( (1/(stddev*sqrt(2*M_PI))) * Riemann(l1,l2,divisions) );
       }
  };

As you can see the class is inherited from RiemannSumCalculus. The IntegratableFunction is redefined, and the CummulativeDistribution function calls the inherited Riemann, which, in turn, will call the local IntegratableFunction, instead of the inherited null-value place holder function. And since this is a class, we can create a more easy way to access this, by calling this method from a function:

1
2
3
4
5

double cum_norm(double x)
  {
   GaussCummulativeFunction normaldistribution;      
   return(normaldistribution.CummulativeDistribution(1,-7.0,x,1000000));   
  }

Perhaps 1,000,000 divisions seem a bit too much, but it’s necesary to keep results accurate.

What follows is the MQL5 version of the Black-Scholes procedure written by George Levy in his book, “Computational finance using C and C++”, page 76 (with some small modifications):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

struct Greeks
  {
   double delta;
   double gamma;
   double vega;
   double theta;
   double rho;
  };  
 
void black_scholes(double& value, Greeks &greeks, double s0, double x, double sigma, double t, double r, double q, bool iscall, long &iflag)
    {
     /* 
     Input parameters:
     =================
     s0 - the current price of the underlying asset
     x - the strike price
     sigma - the volatility
     t - the time to maturity
     r - the interest rate
     q - the continuous dividend yield
     iscall - true if option is a call
 
     Output parameters:
     ==================
     value - the value of the option
     greeks[] - the hedge statistics output;
     iflag - an error indicator
     */
 
     greeks.delta=0.0;
     greeks.gamma=0.0;
     greeks.vega=0.0;
     greeks.theta=0.0;
     greeks.rho=0.0;
     double one=1.0,two=2.0,zero=0.0;
     double eps,d1,d2,temp,temp1,temp2,np;
     /* Check if any of the the input arguments are too small */
     eps=1.0e-16;
     if ( (x < eps) || (sigma < eps) || (t < eps) ) 
       { 
        iflag = 2;
        return;
       }
     temp = log(s0/x);
     d1 = temp+(r-q+(sigma*sigma/two))*t;
     d1 = d1/(sigma*sqrt(t));
     d2 = d1-sigma*sqrt(t);
     /* evaluate the option price */
     if (iscall==true)
       value = (s0*exp(-q*t)*cum_norm(d1)- x*exp(-r*t)*cum_norm(d2));
     else
       value = (-s0*exp(-q*t)*cum_norm(-d1) + x*exp(-r*t)*cum_norm(-d2));
     /* then calculate the Greeks */
     temp1 = -d1*d1/two;
     d2 = d1-sigma*sqrt(t);
     np = (one/sqrt(two*M_PI)) * exp(temp1);
     if (iscall==true) 
       { 
        /* a call option */
        greeks.delta = (cum_norm(d1))*exp(-q*t); 
        greeks.theta = -s0*exp(-q*t)*np*sigma/(two*sqrt(t)) + q*s0*cum_norm(d1)*exp(-q*t)- r*x*exp(-r*t)*cum_norm(d2); 
        greeks.rho = x*t*exp(-r*t)*cum_norm(d2);
       }
     else 
       { 
        /* a put option */
        greeks.delta = (cum_norm(d1) - one)*exp(-q*t);
        greeks.theta = -s0*exp(-q*t)*np*sigma/(two*sqrt(t)) - q*s0*cum_norm(-d1)*exp(-q*t) + r*x*exp(-r*t)*cum_norm(-d2); 
        greeks.rho = -x*t*exp(-r*t)*cum_norm(-d2);
       }
     greeks.gamma = np*exp(-q*t)/(s0*sigma*sqrt(t)); 
     greeks.vega = s0*sqrt(t)*np*exp(-q*t);
    return;
    }

And the following , translated from the same book, to get the implied volatility:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

void implied_volatility(double value, double s0, double x, double& sigma[],double t, double r, double q, bool iscall, long& iflag)
   {
    /* Input parameters:
    =================
    value - the current value of the option
    s0 - the current price of the underlying asset
    x - the strike price
    sigma[] - the input bounds on the volatility: sigma[0], the lower bound and, sigma[1],the upper bound
    t - the time to maturity
    r - the interest rate
    q - the continuous dividend yield
    iscall - true if option is a call;
 
    Output parameters:
    ==================
    sigma[] - the element sigma[0] contains the estimated implied volatility
    iflag - an error indicator
    */
    double zero=0.0;
    double fx, sig1, sig2;
    double val,tolx;
    double temp,eps,epsqrt,temp1,v1;
    long max_iters, i, ind, ir;
    double c[20];
    double sig,vega;
    Greeks greeks;
    long done;
    tolx = eps;
    eps=1.0e-16;
    epsqrt = sqrt(eps);
    if (iscall == true) /* a call option */
      temp1 = MathMax(s0*exp(-q*t)-x*exp(-r*t),zero);
    else /* a put option */
      temp1 = MathMax(x*exp(-r*t)-s0*exp(-q*t),zero);
    v1 = fabs(value-temp1);
    if (v1 <= epsqrt) 
      { /* the volatility is too small */
       iflag = 3;
       return;
      }
   iflag = 0;
   i = 0;
   max_iters = 50;
   done = 0;
   sig = sigma[0]; /* initial estimate */
   val = value;
   while ((i < max_iters) && (!done)) 
        { /* Newton iteration */
         black_scholes(val,greeks,s0,x,sig,t,r,q,iscall,iflag); /* compute the Black-Scholes option value, val */
         vega = greeks.vega; /* and vega. */
         sig1 = sig - ((val - value)/vega); /* compute the new estimate of sigma using Newton’s method */
         if (tolx > fabs((sig1 - sig)/sig1)) 
           { /* check whether the specified accuracy has been reached */
             done = 1;
           }
         sig = sig1; /* up date sigma */
         ++i;
        }
   sigma[0] = sig1; /* return the estimate for sigma */
   return;
  }

Now , keeping these parts as the beginning of our script, we will complete our script to test the Black-Scholes model.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

//+------------------------------------------------------------------+
//| Script program start function                                    |
//+------------------------------------------------------------------+
void OnStart()
  {
   double StockPrice=100.00;
   double SelectedStrike=100.00;
   double r=0.1;
   double sigma=0.3;
   double q=0.06;
   ObjectsDeleteAll(ChartID(),-1,-1);
   int s0;
   Greeks greeks;
   double value;
   double t;
   int T;   
   long iflag;
 
 
   for (T=10;T>=1;T--)
      {
       t=0.1*T;
       black_scholes(value, greeks, StockPrice, SelectedStrike, sigma, t, r, q, true, iflag);       
       Print(DoubleToString(t,1)," :: ",DoubleToString(value,3)," ",DoubleToString(greeks.delta,3)," ",DoubleToString(greeks.gamma,3)," ",DoubleToString(greeks.vega,3)," ",DoubleToString(greeks.theta,3)," ",DoubleToString(greeks.rho,3));
      }
   Print("Time    Value     Delta    Gamma    Vega    Theta      Rho");
   Print("Calls");
   Print("");
   for (T=10;T>=1;T--)
      {
       t=0.1*T;
       black_scholes(value, greeks, StockPrice, SelectedStrike, sigma, t, r, q, false, iflag);       
       Print(DoubleToString(t,1)," :: ",DoubleToString(value,3)," ",DoubleToString(greeks.delta,3)," ",DoubleToString(greeks.gamma,3)," ",DoubleToString(greeks.vega,3)," ",DoubleToString(greeks.theta,3)," ",DoubleToString(greeks.rho,3));
      }      
   Print("Time    Value     Delta    Gamma    Vega    Theta      Rho");   
   Print("Puts");  
   Print("");
   Print("Continuous dividend yield: ",q*100,"%");  
   Print("Implied volatility: ",sigma*100,"%");
   Print("Riskless rate: ",r*100,"%");
   Print("Selected strike: ",SelectedStrike);
   Print("Stock price: ",StockPrice);
   Print("ASSUMPTIONS: ");         
  }
//+------------------------------------------------------------------+

And the output should look like this:

Now delete the previous added lines that completed the script, and add the following ones, to test implied volatility function:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

//+------------------------------------------------------------------+
//| Script program start function                                    |
//+------------------------------------------------------------------+
void OnStart()
  {
  double S = 10.0;
  double X = 10.5;
  double r = 0.1;
  double sigmat = 0.5;
  double q = 0.04;  
  Greeks greeks;
  double sigma[2];
  double value, T;
  long i, ifail, put;
  double origsigma=sigmat;
  long flag;
  ifail = 0;
  for (i = 5;i >= 1; i--) 
    {
     T = (double)i*0.5;
     black_scholes(value,greeks,S,X,sigmat,T,r,q,true,flag);
     sigma[0] = 0.05;
     sigma[1] = 1.0;
     implied_volatility(value,S,X,sigma,T,r,q,true,flag);
     printf("%8.4f %15.4f    %15.4f     (%8.4e) ",T,value,sigma[0],fabs(sigmat-sigma[0]));  
     sigmat = sigmat - 0.1;
    }
  printf (" Time(years)  Option value  True sigma   Error");
  Print("");
  Print("Underlying= ",DoubleToString(S,2));
  Print("Strike= ",DoubleToString(X,2));
  Print("Continuous dividend yield= ",DoubleToString(q*100,2),"%");
  Print("Implied volatility= ",DoubleToString(origsigma*100,2),"%");
  Print("Riskless rate= ",DoubleToString(r*100,2),"%");
  Print("x= ",DoubleToString(X,2));
  Print("S= ",DoubleToString(S,2));
  Print("ASSUMPTIONS");  
  return;
 }

The script plugs some values into the Black-Scholes model, gets option values, then sets a guess range and calls the implied volatility function, that gives pretty accurate results:

Volatility. A word that generates panic for investors as well as faster heartbeats for traders. How many times haven’t you tried before to trade only trending markets and catch the momentum ?

According to InvestorWords.com, volatility is the relative rate at which the price of a security moves up and down. Volatility is found by calculating the annualized standard deviation of daily change in price. If the price of a stock moves up and down rapidly over short time periods, it has high volatility. If the price almost never changes, it has low volatility. So volatility is measured by standard deviation (noted with greek lowercase sigma letter). And what’s the most popular indicator based on standard deviation ? You guessed, the famous Bollinger Bands. Bollinger Bands (BB) is one of the first indicators that you have learned to use in trading. You have been told that, there is a signal to buy or sell whenever the market touches one of the bands, followed by a possible walk along the band, and afterwards when price turns away, it will go like that until it touches the moving average. This rule actually doesn’t tell too much. There is nothing saying how much it will walk along the band until it turns back. Which you may find very frustrating on your own … equity. If you graph the basis of this indicator, the standard deviation, you will see a sinusoidal chart. Volatility goes up and down in quite a continuous pattern, without swift moves. Since it’s not making swift moves, it means the volatility itself is more predictible than the price.  Since it’s forecastable, why not using BBs over volatility ? But wait. Standard deviation is relative. It measures the dispersion over the analyzed period. If we add the BBs over the standard deviation, it means we will use the standard deviation of the standard deviation to catch moves in volatility! This time there is no fear of false positives, because the analysed data set, standard deviation of the price, is a continuous function. Second, even if the signal is wrong and the volatility turns back and trends down towards its moving average, there’s not too much damage done, because the volatility is already down when signal is taken, and a move down in volatility will mean less movement in price. The bluish line is the standard deviation of last 20 bars opening price. Signals we are interested in happen when volatility crosses its own upper BB. Of course, we are not interested in crosses with lower BB, because they mean volatility is going down faster than normal. During a trend, a powerful countermovement will appear like the volatility would be going down. Best signals are when crosses with the upper BB happen at a very reduced historical volatility – below 20% of the on-screen range. If you compare with the other signals on chart, BB over price intersections with the price, you can see that this one may cross even when the volatility is within its own BB bands, so this is a way to filter lots of error-prone BB signals that are given by price BB intersections. A good entry-exit criteria would be that the distance between the upper volatility BB band and the volatility to be below 2% of volatility range. Below is the MQL4 transcript of the Bollinger Bands over Standard Deviation indicator.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131

//+------------------------------------------------------------------+
//|                                                    BBoverSTD.mq4 |
//|                                                 Bogdan Caramalac |
//|                                     mailto:fxeconomist@yahoo.com |
//+------------------------------------------------------------------+
#property copyright "Bogdan Caramalac"
#property link      "mailto:fxeconomist@yahoo.com"
 
#property indicator_separate_window
#property indicator_buffers 4
#property indicator_color1 LightSeaGreen //STDDEV
#property indicator_color2 Blue          //MA
#property indicator_color3 Yellow        //Upper BB
#property indicator_color4 Yellow        //Lower BB
 
//---- input parameters
extern int       STDLEN=20;
extern int       BBLEN=10;
extern double    BBMULT=2.0;
extern string    MATYPE="SMA";
extern int       MALEN=0;
extern int       Logarithm=0;
 
double ExtMapBuffer1[];
double ExtMapBuffer2[];
double ExtMapBuffer3[];
double ExtMapBuffer4[];
//+------------------------------------------------------------------+
//| Custom indicator initialization function                         |
//+------------------------------------------------------------------+
int init()
  {
//---- indicators
   SetIndexStyle(0,DRAW_LINE, 0, 1, indicator_color1);
   SetIndexBuffer(0, ExtMapBuffer1);
   SetIndexStyle(1,DRAW_LINE, 0, 1, indicator_color2);
   SetIndexBuffer(1, ExtMapBuffer2);
   SetIndexStyle(2,DRAW_LINE, 0, 1, indicator_color3);
   SetIndexBuffer(2, ExtMapBuffer3);
   SetIndexStyle(3,DRAW_LINE, 0, 1, indicator_color4);
   SetIndexBuffer(3, ExtMapBuffer4);
//----
   SetIndexDrawBegin(0,STDLEN);
 
   SetIndexDrawBegin(1,STDLEN+BBLEN-1);
   SetIndexDrawBegin(2,STDLEN+BBLEN-1);
   SetIndexDrawBegin(3,STDLEN+BBLEN-1);
   return(0);
  }
 
//+------------------------------------------------------------------+
//| Custom indicator iteration function                              |
//+------------------------------------------------------------------+
int start()
   {
   if (Bars<=MathMax(STDLEN+BBLEN,MALEN))      
      return(0);    
   int pos=Bars-1;    
   ArraySetAsSeries(ExtMapBuffer1,true);    
   while (pos>=0)
     {
      if (MATYPE=="SMA")
        {
         ExtMapBuffer1[pos]=iStdDev(Symbol(),Period(),STDLEN,0,MODE_SMA,MODE_OPEN,pos);
         if (Logarithm==1&&ExtMapBuffer1[pos]!=0.00)
           ExtMapBuffer1[pos]=MathLog(ExtMapBuffer1[pos]);
        }
      if (MATYPE=="EMA")
        {
         ExtMapBuffer1[pos]=iStdDev(Symbol(),Period(),STDLEN,0,MODE_EMA,MODE_OPEN,pos);
         if (Logarithm==1&&ExtMapBuffer1[pos]!=0.00)
           ExtMapBuffer1[pos]=MathLog(ExtMapBuffer1[pos]);
        }
      if (MATYPE=="SMMA")
        {
         ExtMapBuffer1[pos]=iStdDev(Symbol(),Period(),STDLEN,0,MODE_SMMA,MODE_OPEN,pos);
         if (Logarithm==1&&ExtMapBuffer1[pos]!=0.00)
           ExtMapBuffer1[pos]=MathLog(ExtMapBuffer1[pos]);
        }
      if (MATYPE=="LWMA")
        {
         ExtMapBuffer1[pos]=iStdDev(Symbol(),Period(),STDLEN,0,MODE_LWMA,MODE_OPEN,pos);
         if (Logarithm==1&&ExtMapBuffer1[pos]!=0.00)
           ExtMapBuffer1[pos]=MathLog(ExtMapBuffer1[pos]);
        }
       pos--;
     }
   pos=Bars-1;
   while(pos>=0)
     {
      if (MATYPE=="SMA")
        {
         if (MALEN!=0)
           ExtMapBuffer2[pos]=iMAOnArray(ExtMapBuffer1,0,MALEN,0,MODE_SMA,pos);
         else
           ExtMapBuffer2[pos]=EMPTY_VALUE;
        }
      if (MATYPE=="EMA")
        {
         if (MALEN!=0)
           ExtMapBuffer2[pos]=iMAOnArray(ExtMapBuffer1,0,MALEN,0,MODE_EMA,pos);
         else
           ExtMapBuffer2[pos]=EMPTY_VALUE;
        }
      if (MATYPE=="SMMA")
        {
         if (MALEN!=0)
           ExtMapBuffer2[pos]=iMAOnArray(ExtMapBuffer1,0,MALEN,0,MODE_SMMA,pos);
         else
           ExtMapBuffer2[pos]=EMPTY_VALUE;
        }
      if (MATYPE=="LWMA")
        {
         if (MALEN!=0)
           ExtMapBuffer2[pos]=iMAOnArray(ExtMapBuffer1,0,MALEN,0,MODE_LWMA,pos);
         else
           ExtMapBuffer2[pos]=EMPTY_VALUE;
        }
       pos--;
     }
   pos=Bars-1;
   while(pos>=0)
     {
      ExtMapBuffer3[pos]=EMPTY_VALUE;
      ExtMapBuffer4[pos]=EMPTY_VALUE;
      ExtMapBuffer3[pos]=iBandsOnArray(ExtMapBuffer1,0,BBLEN,BBMULT,0,MODE_HIGH,pos);
      ExtMapBuffer4[pos]=iBandsOnArray(ExtMapBuffer1,0,BBLEN,BBMULT,0,MODE_LOW,pos);
      pos--;
     }
   return(0);
  }

Parameters:

STDLEN – length of the period whose standard deviation is calculated;

BBLEN – length of the period whose BB bands are calculated for;

BBMULT – standard deviation multiplicator for BB bands;

MATYPE – a helper Moving Average over the volatility is created, of this type ; same type is applied to the construction of the standard deviation in first place;

MALEN – period of the helper Moving Average (turned off with 0)

Logarithm – used for logarithming the scale ; for 0, disabled, for 1, natural logarithm;

Credits to Irtron and Ruptor from the mql4.com forum for sorting out this indicator.

The iMAOnArray function is buggy; an MQL4 indicator file can contain more than one loop used for calculation.

Let’s take a peek at the anatomy of this MQL4 indicator.

Lines 9 to 15 are the intro of the indicator ; it is specified that the indicator is in a separate window , number of buffers and coloring for each;

Lines 17 to 22 are the definition of parameters; what makes them parameters, as opposed to what is known as global variables in other programming languages , (for instance the Public declarations in Visual Basic) is the keyword extern in the front of the type ; when the indicator is installed (dragged over the chart) , these parameters can be modified . Also these parameters can be modified any time by the user ; but no expert advisor or script can touch the parameters of an indicator running in a window.

Lines 24 to 27 are the buffers ; since we specified that are 4 of them, 4 are defined. Indicator buffers are numbers that denominate arrays inside indicators that contain data. For instance, if an indicator would copy OHLC bar data to indicator buffers, 0 would be for open prices, 1 for high , 2 for low, 3 for close. In our case, as you will see later, 0 is for standard deviation, 1 for helper moving average, 2 for higher BB band and 3 for lower BB band.

Lines 31 to 49 make up the init() function. This function is called every time the chart parameters are changed (symbol , periodicity) or connection coming back up. The function defines the drawing style for each of the buffers and assigns the arrays to indicator buffers. Also specifies where drawing point begins for each buffer. Drawing point should be carefully calculated, so that data that is the base for buffer to be there previously. For instance, if you calculate a 10 element moving average, drawing point should not be larger than 10 elements below the count of bars.

Lines 54 to 131 make up the start() function. start() is triggered at every incoming quote. It starts with a condition checking that there are enough Bars to draw the indicator. Then, sets the position to start drawing. Position is a bar index. Indicator is calculated from a positive position to zero (current bar).  The ArraySetAsSeries() function alters the working mode of an array, setting it work like time series. This does not affect the array per se. Rather, it tells the special functions that work with arrays to treat arrays reversed. The functions that calculate indicators over arrays (like iMAOnArray() , iStdDevOnArray() and so on) pass the array from left to right, from lower indexes to higher indexes. The ArraySetAsSeries() applied to an array will make these functions pass the array from right to left, from higher indexes to lower indexes, exactly how a custom indicator loop does. Then what follows are the loops. In a simple indicator quite everything can be done in a single loop, but here three loops do the trick. The first loop will calculate the standard deviation ; the second loop will calculate the helper moving average, and finally the third loop will calculate the upper and lower BBs.

Same indicator, MQL5 version

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153

//+------------------------------------------------------------------+
//|                                                    BBoverSTD.mq5 |
//|                                       Copyright Bogdan Caramalac |
//|                                                  mqlmagazine.com |
//+------------------------------------------------------------------+
#property copyright "Bogdan Caramalac"
#property link      "mqlmagazine.com"
#property version   "1.02"
 
#property indicator_separate_window
#property indicator_buffers 4
#property indicator_applied_price PRICE_OPEN
 
#property indicator_plots   4
#property indicator_type1 DRAW_LINE
#property indicator_label1 "Stddev"
#property indicator_color1 LightSeaGreen //STDDEV
#property indicator_type2 DRAW_LINE
#property indicator_label2 "Helper MA"
#property indicator_color2 Blue          //MA
#property indicator_type3 DRAW_LINE
#property indicator_label3 "Upper BB"
#property indicator_color3 Yellow        //Upper BB
#property indicator_type4 DRAW_LINE
#property indicator_label4 "Lower BB"
#property indicator_color4 Yellow        //Lower BB
 
//---- input parameters
input int       STDLEN=20;
input int       BBLEN=10;
input double    BBMULT=2.0;
input string    MATYPE="SMA";
input int       MALEN=2;
input int       Logarithm=0;
 
double ExtMapBuffer1[];
double ExtMapBuffer2[];
double ExtMapBuffer3[];
double ExtMapBuffer4[];
 
#include <MovingAverages.mqh>
 
int StdDevHandle;
 
//+------------------------------------------------------------------+
//| Custom indicator initialization function                         |
//+------------------------------------------------------------------+
int OnInit()
  {
//--- indicator buffers mapping
   SetIndexBuffer(0, ExtMapBuffer1);
   SetIndexBuffer(1, ExtMapBuffer2);
   SetIndexBuffer(2, ExtMapBuffer3);
   SetIndexBuffer(3, ExtMapBuffer4);
//----
   PlotIndexSetInteger(0,PLOT_DRAW_BEGIN,STDLEN);
   PlotIndexSetInteger(1,PLOT_DRAW_BEGIN,STDLEN+BBLEN-1);
   PlotIndexSetInteger(2,PLOT_DRAW_BEGIN,STDLEN+BBLEN-1);
   PlotIndexSetInteger(3,PLOT_DRAW_BEGIN,STDLEN+BBLEN-1);
//---
   //we create iStdDev handler for use in main cycle;
   if (MATYPE=="SMA")
     StdDevHandle=iStdDev(Symbol(),Period(),STDLEN,0,MODE_SMA,PRICE_OPEN);
   if (MATYPE=="EMA")
     StdDevHandle=iStdDev(Symbol(),Period(),STDLEN,0,MODE_EMA,PRICE_OPEN); 
   if (MATYPE=="LWMA")
     StdDevHandle=iStdDev(Symbol(),Period(),STDLEN,0,MODE_LWMA,PRICE_OPEN); 
   if (MATYPE=="SMMA")
     StdDevHandle=iStdDev(Symbol(),Period(),STDLEN,0,MODE_SMMA,PRICE_OPEN);  
   return(0);
  }
//+------------------------------------------------------------------+
//| Custom indicator iteration function                              |
//+------------------------------------------------------------------+
int OnCalculate(const int rates_total,
                const int prev_calculated,
                const datetime& time[],
                const double& open[],
                const double& high[],
                const double& low[],
                const double& close[],
                const long& tick_volume[],
                const long& volume[],
                const int& spread[])
   {
    double res[]; //array to hold current iStdDev value;
    double buffer_helper[500];
    double stddevonstddev=0.0;    //current stddev on stddev
    double squaredsum=0.0;        //current squared sum
    double bbma=0.0;              //current ma for bollinger bands calculus
    double bbsum=0.0;             //current sum for calculus of bbma
    double prevma=0.0;            //previous helper moving average value, for use with SMMA or LWMA   
    int buff_stddevs=0;           //used length of stddevs buffer
    int buff_helper_len=0;        //used length of helper buffer   
    int startpos=MathRound(MathMin(prev_calculated,rates_total-1)); //this is the start position ; it goes UPWARD, we are on an array, not on series
    if (rates_total<STDLEN)
      return(rates_total);
    if (startpos<STDLEN)
      startpos=STDLEN;
    for (int pos=startpos;pos<rates_total;pos++) //main cycle, going from startpos to rates_total
       {
        //Reads 1 element from position rates_total-pos, buffer 0 of StdDevIndicator calculus designated by StdDevHandle
        //rates_total-pos to convert position ; buffers are time series (curent value has index 0)
        CopyBuffer(StdDevHandle,0,rates_total-pos,1,res);
        ExtMapBuffer1[pos]=res[0];//copy value from temporary res[0] array index to final ExtMapBuffer1        
        if (Logarithm==1)
          ExtMapBuffer1[pos]=MathLog(ExtMapBuffer1[pos]);
        if (Logarithm==2)
          ExtMapBuffer1[pos]=MathLog10(ExtMapBuffer1[pos]);
        if (pos>STDLEN+BBLEN)
          {
           //enough values to calculate Bollies over volatility
           squaredsum=0.0;
           bbsum=0.0;
           //calculating the moving average for bollinger bands
           for (int j=pos-BBLEN+1;j<=pos;j++)
              bbsum=bbsum+ExtMapBuffer1[j];
           bbma=bbsum/BBLEN;
           //calculating the squared sum for the stddev over stddev needed for bollinger bands
           for (int j=pos-BBLEN+1;j<=pos;j++)
              squaredsum=squaredsum+(ExtMapBuffer1[j]-bbma)*(ExtMapBuffer1[j]-bbma);
           //stddev on stddev and bollinger bands
           stddevonstddev=MathSqrt(squaredsum/BBLEN);
           ExtMapBuffer3[pos]=bbma+BBMULT*stddevonstddev;
           ExtMapBuffer4[pos]=bbma-BBMULT*stddevonstddev;
           if (pos>MALEN+BBLEN+STDLEN)
             {
              if (MALEN!=0) //goes in only if helper moving average is indeed enabled
                {
                 //making buffer for helper MA
                 for (int j=1;j<=MALEN;j++)    
                    buffer_helper[MALEN-j+1]=ExtMapBuffer1[pos-j+1];            
                 //calculating different kinds of moving averages, by calling moving average methods from MovingAverages.mqh
                 if (MATYPE=="SMA")
                   ExtMapBuffer2[pos]=SimpleMA(MALEN,MALEN,buffer_helper);
                 if (MATYPE=="EMA")
                   {
                    ExtMapBuffer2[pos]=ExponentialMA(MALEN,MALEN,prevma,buffer_helper);
                    prevma=ExtMapBuffer2[pos];
                   }
                 if (MATYPE=="SMMA")
                   {
                    ExtMapBuffer2[pos]=SmoothedMA(MALEN,MALEN,prevma,buffer_helper);
                    prevma=ExtMapBuffer2[pos];
                   }
                 if (MATYPE=="LWMA")
                   ExtMapBuffer2[pos]=LinearWeightedMA(MALEN,MALEN,buffer_helper);      
                }//if (MALEN!=0)
             }//if (pos>MALEN+STDLEN)                           
          }//else if if (buff_stddevs<BBLEN)
       }//for (pos=startpos;pos<rates_total;pos++)
   return(rates_total);
  }

Well, programming in MQL5 is signifiantly harder. MQL5 has a whole different way of approaching indicators, so different that comparisons to MQL4 are practically pointless. The indicator begins in a similar manner, with a larger intro, lines 10-26 . The intro has a much wider number of settings compared to MQL4. Then follow the parameters, lines 29-34, and finally the buffers, lines 36-39. Note in lines 29-34 the replacement of extern by input , which takes its place in MQL5. extern still remains valid in MQL5, but it has a different role.

Until this moment it doesn’t seem too complicated, because code is similar to MQL4. But now it takes a complete different turn…
First, an include of the MovingAverages.mqh on line 41. This will be needed below, because the different moving averages calculations will be done by calling moving average routines residing in this lib. Then, on line 43, public declaration of Standard Deviation indicator handle (only one, because we pick by moving average type). In MQL5, calls to indicators don’t return indicator values, as they were doing in MQL4. Rather, they return a handle. The handle is needed later to get indicator values, in a calls to CopyBuffer(). The OnInit(), spanning on lines 48-71, is similar again to MQL4 init() , at least in the 50-59 lines , where there are buffer assignations and draw begin setups. The OnInit() ends with calls to iStdDev() ; the indicator will be used inside the main loop, but the handle is generated once! Four calls to iStdDev, generating the unique handle for the chosen type of moving average required by MATYPE parameter.

The OnCalculate() event is practically the new master loop. This function has a kind of a mysterious prototype. Its implementation details are not fully known, so the function allows a pretty wide range of prototypes. The one I used in the indicator is the default one that you get when you create a new indicator. As opposed to MQL4, when index bars are descendant from Bars to 0, current bar, in MQL5, index bars are ascendant from prev_calculated-1 to rates_total-1.

Following the declarations of the variables, the loop begins in line 100. First thing to do, we get the current value of the standard deviation. Since we have the handler, we call the CopyBuffer() to retrive the value for the current position. The current position is the cycle variable pos. However, CopyBuffer() understands position as a position in a series, not as a position in an array. Therefore, we will copy 1 value from rates-total-pos, from the first series, 0. If the indicator would have returned more than one value, say the indicator would have returned more value, like a Heiken Ashi, for instance, that returns bar informations, we would have had more than one series, adressing series 0, 1, 2 and 3 to get values of Heiken Ashi bar prices. The values got with CopyBuffer() are put in an array. But we need one number, so the array where we put the data , res will have only one value, res[0], which is copied to our first buffer, ExtIndexBuffer1, and then logarithming is applied, according to Logarithm parameter, lines 106-109 (now the decimal logarithm is included too, besides the natural).

What follows is pretty easy to follow. We count if we have enough values to start calculating the Bollinger Bands over the standard deviation. When there is enough data , (“if” branch line 110), we go back BBLEN values and calculate the average, then we do again same loop and calculate the standard deviation over the standard deviation, then finally Bollinger Bands , lines 124-125.
Same as before, but with the condition of having at least one standard deviation over standard deviation calculated, we check to see if we have MALEN values of these, to compute the first helper moving average. But unlike previous time, we copy values of initial standard deviation in a buffer. Buffer will span from MALEN down to 1, with larger indexes for older values. The reason to do it is that we will pass this buffer as a parameter to moving average methods taken from MovingAverages.mqh, and their inner implementation is passing this way thru the arrays. These are simple functions. Unlike indicators, their results are answers of inner calculations, not handlers. And their results are written in the buffer for the helper moving average, ExtMapBuffer2. With the calculation of the helper moving average, all calculations are done and the loop closes.

Volatility forecasting

This is why I included in the indicator a helper moving average: to help forecast volatility. I would stress, however, that some key requirements to be met before attempting to do so:
1. The BB band channel should be below  2% from historical standard deviation range – this will insure that the signal does not happen accidentally when BB bands are already at distance.
2. Current standard deviation should be below 5% from historical standard deviation high – this will insure that there is a high chance of an explosive volatility growth after the signal.

The normal signal should be the cross of the upper BB band. The exit signal should be determining a weakening in volatility speed. And that happens when volatility tops while BB upper band still going up. To determine this quick, use a quick helper moving average – with a period of 2 . Once that crosses the volatility, you can already consider the exit signal. But it can be determined even quicker, when there is a too large distance between the higher BB band and the standard deviation. One of the best interpretations of this chart would be by converting data – BB bands, standard deviation, moving average etc. to their graphics counterparts – point coordinates on chart. This might tell you for instance when the standard deviation touches the upper BB band.

Provided that you calculate the upper and lower BB for a fixed number of bars maybe WindowBarsPerChart() that gives the number of bars of the chart where your expert advisor or script runs, or a given number of bars – and you extract the highest upper BB and lowest lower BB, let’s name them bbmax and bbmin – you can calculate a virtual graphics position of any value (be it a BB, standard deviation or helper moving average), using a given screen height (say 300 virtual “pixels”). Let’s call this one testvalue. So the position of the testvalue would be:

double position=MathRound( height*(testvalue-bbmin)/bbmax );

This way, a composite condition would be, after conditions 1. and 2. are fulfilled, that there is either a cross or a touch. Exit criteria would be : standard deviation is below upper BB and there is no touch anymore. However, at the first sign of weaking volatility, the exit signal will be triggered, and that might happen too early. It would be good to backcheck the touch status using a lower resolution.

There are two possibly situations that contribute to standard deviation growth: either prices are going either up or down in an accelerated fashion, or prices change direction swiftly from up to down and viceversa with a growing amplitude.

If the volatility kept going up for the last bars , we might presume first condition : that prices are trending. In this case, we can just check the last 2-3 opening prices to see the direction and trade it, if it’s established. But, no matter if direction is established or not, the volatility can still go up. Because volatility is at historically low when we take the signal, and tiny increases mean just the aggitation is growing up, not that the direction is established. Price fluctuations may follow an up-down pattern with growing amplitude, until direction becomes established. However, volatility is still low. Being low, it means that prices don’t move too much – we can afford to lose. No matter which direction we trade, we check at every new bar if we trade it in the good direction. If not, cut loss and trade again. Because if the signal is correct and volatility is going to traverse 30% to 70% of its historical range, we’re in for big bucks!

Volatility forecast is pretty straightforward, and is more manual than automated. Since we expect volatility to be going thru the roof, we can do a linear or parabolic forecast.  The linear model is simple. If we have the current standard deviation on bar 0 (s0) and the expected standard deviation for bar m (sm), we have forecasted standard deviation per bar f(bar)=so+(sm-so)*bar/m.

The parabolic model is harder, because it needs an extra point to define the curvature. This is solvable with an equation system. Given three points (b1,stddev1) , (b2,stddev2) , (b3,stddev3) where b1, b2, b3 are bar indexes and stddev1,stddev2,stddev3 are estimated standard deviations :

Once we have the parameters of the quadratic function that describes the standard deviation according to estimated points, we can generate the standard deviation per each bar, see MQL4 script:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120

double Determinant(double &origa[][],int l1,int c1,int l2,int c2,int jumpline,int jumpcol)
    {
    double a[50,50];
    int degree,i,j,ip,jp,dets;
    double result=0;
    double reshere=0;
    double r;
    string image;
    int ipm,jpm;
    for (i=0;i<50;i++)
       {
       for (j=0;j<50;j++)
          a[i,j]=0.0;
       }
    if (l1==0)
       l1=1;
    if (c1==0)
       c1=1;
    degree=c2-c1+1;
    if (jumpcol!=0)
       degree=degree-1;
    ip=1;
    for (i=l1;i<=l2;i++)
      {
      ipm=ip-1;       
      jp=1;
      if (i!=jumpline)
        {
        for (j=c1;j<=c2;j++)
          {
          jpm=jp-1;
          if (j!=jumpcol)
             {
             r=origa[i-1,j-1]*1.0;                          
             a[ipm,jpm]=r;             
             jp=jp+1;
             }
          }//for (j=c1;j<=c2;j++c2)              
        ip=ip+1;
        }//if (i!=jumpline)
      }//for (i=l1;i<=l2;i++)
    result=0;
    if (degree==1)
       result=0;  
    if (degree==2)
       result=a[1-1,1-1]*a[2-1,2-1]-a[2-1,1-1]*a[1-1,2-1];
    if (degree==3)
       result=a[1-1,1-1] * a[2-1,2-1] * a[3-1,3-1] + 
              a[1-1,2-1] * a[2-1,3-1] * a[3-1,1-1] + 
              a[1-1,3-1] * a[2-1,1-1] * a[3-1,2-1] - 
              a[1-1,3-1] * a[2-1,2-1] * a[3-1,1-1] - 
              a[1-1,2-1] * a[2-1,1-1] * a[3-1,3-1] - 
              a[1-1,1-1] * a[2-1,3-1] * a[3-1,2-1] ;    
    if (degree>3)
       {
       for (dets=1;dets<=degree;dets++)
           {
           reshere=Determinant(origa,1,1,degree,degree,1,dets);
           result=result + MathPow(-1,1+dets)*origa[1-1,dets-1]*reshere;
           }
       }
    return(result);
    }
 
void EstablishStddevFunction(int b1,double stddev1,int b2,double stddev2,int b3,double stddev3,double &a, double &b, double &c)
  {
   double d,da,db,dc;
   double barray[3];
   double stddev[3];
   double det_d[3][3];
   double det_da[3][3];
   double det_db[3][3];
   double det_dc[3][3];
   barray[0]=b1*1.0;
   barray[1]=b2*1.0;
   barray[2]=b3*1.0;
   stddev[0]=stddev1;
   stddev[1]=stddev2;
   stddev[2]=stddev3;
   det_d[0][0]=barray[0]*barray[0];  det_d[0][1]=barray[0];   det_d[0][2]=1;   
   det_d[1][0]=barray[1]*barray[1];  det_d[1][1]=barray[1];   det_d[1][2]=1;
   det_d[2][0]=barray[2]*barray[2];  det_d[2][1]=barray[2];   det_d[2][2]=1;
 
   det_da[0][0]=stddev[0];  det_da[0][1]=barray[0];   det_da[0][2]=1;   
   det_da[1][0]=stddev[1];  det_da[1][1]=barray[1];   det_da[1][2]=1;
   det_da[2][0]=stddev[2];  det_da[2][1]=barray[2];   det_da[2][2]=1;
 
   det_db[0][0]=barray[0]*barray[0];  det_db[0][1]=stddev[0];   det_db[0][2]=1;   
   det_db[1][0]=barray[1]*barray[1];  det_db[1][1]=stddev[1];   det_db[1][2]=1;
   det_db[2][0]=barray[2]*barray[2];  det_db[2][1]=stddev[2];   det_db[2][2]=1;
 
   det_dc[0][0]=barray[0]*barray[0];  det_dc[0][1]=barray[0];   det_dc[0][2]=stddev[0];   
   det_dc[1][0]=barray[1]*barray[1];  det_dc[1][1]=barray[1];   det_dc[1][2]=stddev[1];
   det_dc[2][0]=barray[2]*barray[2];  det_dc[2][1]=barray[2];   det_dc[2][2]=stddev[2];
 
   d=Determinant(det_d,1,1,3,3,0,0);
   da=Determinant(det_da,1,1,3,3,0,0);
   db=Determinant(det_db,1,1,3,3,0,0);
   dc=Determinant(det_dc,1,1,3,3,0,0);   
   a=da/d;
   b=db/d;
   c=dc/d;
  }
 
//+------------------------------------------------------------------+
//| script program start function                                    |
//+------------------------------------------------------------------+
int start()
  {
   double aa,bb,cc;
   Print("Standard Deviation parabolic forecasting example");        
   EstablishStddevFunction(0,0.003,3,0.006,9,0.1,aa,bb,cc);
   Print("Forecasted standard deviations");
   for (int bar=0;bar<10;bar++)
      {
       Print("bar ",DoubleToStr(bar,0),"  stddev=",DoubleToStr(aa*bar*bar+bb*bar+cc,4));
      }
   return(0);
  }
//+------------------------------------------------------------------+

Note that the Determinant function has a recursive application, up to the degree 3, where Sarrus rule is applied. Thus you can use this function to calculate n-degree determinants – but be careful on time and memory allocation requirements. An MQL5 prototype of this function will look like this:

double Determinant(double &origa[][50],ushort l1,ushort c1,ushort l2,ushort c2,ushort jumpline,ushort jumpcol)

Note that the second dimension is fixed at 50. MQL5 does not support unspecified dimensions larger than one.

All of these might sound good, but don’t forget that we don’t trade volatility. We don’t have a price direction signal.

But the price direction can be extracted from volatility evolution.

Price forecasting from volatility forecast

We have to consider that at every new bar, a price goes out of analysis and another price comes in. If we have oldest for oldest price and newest for the incoming price, we have:

New Average = Old Average – Oldest member/N + Newest member/N ;

Now, given that we plotted already the following standard deviations, the question is, which is the newest price that will give the new standard deviation in the queue?

So we take the estimated new standard deviation, according to the model, and we square it : thus we have the variance. Multiplying the variance by N (number of prices in the analysis), we start shaping up the equation for the newest member.  Taking into account n elements, from P1 (the element thrown out) to Pn (the last element), Pn+1 (the new price that has to be determined) and the current average, we form the standard deviation equation, by squaring the requested standard deviation and multiplying it by n, which yields the sum of squares Pi – new average , which is computed as above, cutting out the P1 influence and adding Pn+1 influence. We use as helper a variable called avgc , which is the average less the influence of P1: (Needless to say, equation is written for the case standard deviation is calculated using a regular simple moving average)

So what you can see is what it was expected. Every standard deviation appears as a result of a new price, which can be either up, or down, which are, of course, roots a quadratic equation. I grouped the elements in order to see the coefficients for free Pn+1, squared Pn+1 and free member. Given m forecasted standard deviations, we have 2^m forecasted prices final after m bars. Of course, these are not to be generated straight ; they form a tree ; so first calculation will yield two prices ; every one of them will enter the price based for a new calculation and so on. So we will have 2, 4, 8, 16…2^m prices until the end. Most likely, the price will not have an amplified ranging movement for all the m bars. Rather, we can expect a few bars to be like that, after that the direction will be established. It is good to keep the high and low prices per each calculated bar. We can be whipsawed at the beginning, during a few swings – and here the estimations will be useful to calculate possible losses – but after these swings price movements will be way larger than in the swing period. My advice is that this method to be used on longer timeframes – larger than four hours. It can work on shorter timeframes, but big volatility catches on longer timeframes can yield spectacular results.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

void CalculateStats(double &data[],int lastindex,double &avg, double &stddev)
  {
   double sum=0;
   int i;
   for (i=0;i<=lastindex;i++)
      {
       sum=sum+data[i];
      }
   avg=sum/(lastindex+1);
   sum=0;
   for (i=0;i<=lastindex;i++)
      {
       sum=sum+(data[i]-avg)*(data[i]-avg);
      }
   stddev=MathSqrt(sum/(lastindex+1));
  }
 
void CalculateNextPrices(double &p[],int lastindex,double newstddev,double &newprice1,double &newprice2)
  {
   double avg,avgc,stddev,suma2pi,sumapi2,sumapimavgc,sumapimavgc2,delta,a,b,c;
   int n,i;
   CalculateStats(p,lastindex,avg,stddev);
   n=lastindex+1;
   avgc=avg-p[0]/n;
   for (i=1;i<=lastindex;i++)
     {
      suma2pi=suma2pi+(2*p[i]);
      sumapi2=sumapi2+(p[i]*p[i]);
      sumapimavgc=sumapimavgc+(p[i]-avgc);
      sumapimavgc2=sumapimavgc2+(p[i]-avgc)*(p[i]-avgc);
     }
   a=1-(1.0/n);
   b=(2.0*avgc/n)-(2.0/n)*sumapimavgc-2.0*avgc;
   c=sumapimavgc2+avgc*avgc-newstddev*newstddev*n;
 
   delta=b*b-4.0*a*c;
   newprice1=(-b-MathSqrt(delta))/(2.0*a);
   newprice2=(-b+MathSqrt(delta))/(2.0*a);
  }

The first function calculates the statistical parameters : average and standard deviation. The second function calculates the new prices that match up the new standard deviation. Both arrays are zero-based. The lastindex parameter is the last subscript that contains data. Note the use of integer constants in formulas that calculate double variables. These constants must be written in a double fashion : 1.0 instead of 1, 2.0 instead of 2, and so on , otherwise results are error-prone.

Be careful when using parabollic standard deviation calculus. If the first chosen standard deviation is before parabola peak, the standard deviation got from the function may get to zero or negative, where real roots of the price quadratic function will be one or none – complex roots don’t have any meaning here!