ExpertSignal.mqh bug and others


Hello again!

Analyzing my EA I think that Direction function from ExpertSignal.mqh has a bug.

At the begining it states that if the result from checked signals for long and short position for a specified Signal is 0.0 (Ex.: SignalAC.mqh) this should not be conted for votes number at var number.

- 'int    number=(result==0.0)? 0 : 1;      // number of "voted" '

But, at the end of the function it simples put "number++" independent on Signal result. So, if you have any signal that has 'no objection' on Long/Short positions, and return 0.0, this still counts for the weighted algorithim making the final result goes wrong ( for arithmetic mean calculation!).

Let's peek an example:

- I have 2 Signals check: AC and BearsPower.

- AC.mqh return 90.0

- BearsPower return 0.0 (as stated in documentation this indicates no objection)

- The final calculation will be 45.0. But it should have been 90.0.

This will also happend for ITF, which was supposed to be just a filter.

I have modified the code, making the Direction function check if the direction variable is different from 0.0 BEFORE summing it as a vote, but I don't think that this solves the problem.

//| Detecting the "weighted" direction                               |
double CExpertSignal::Direction(void)
   long   mask;
   double direction;
   double result=m_weight*(LongCondition()-ShortCondition());
   int    number=(result==0.0)? 0 : 1;      // number of "voted"
   int    total=m_filters.Total();
//--- loop by filters
   for(int i=0;i<total;i++)
      //--- mask for bit maps
      //--- check of the flag of ignoring the signal of filter
      CExpertSignal *filter=m_filters.At(i);
      //--- check pointer
      //--- the "prohibition" signal
      if(direction==EMPTY_VALUE) {
         Print (__FUNCSIG__," !!!!PROHIBITION SIGNAL!!!");//#
      //--- check of flag of inverting the signal of filter
//#################################### BELOW LINE WAS ADDED 
      if (direction != 0.0)
//--- normalization
//--- return the result
   Print (__FUNCSIG__," Calculando resultados! Resultado:",result," Voteds:",number);//#

Am I getting crazy? Was that supposed to behave like the original code? How can we differentiate the "don't vote" from the real "0" (I mean, 0 stating for no condition for buying)

Another bug:

- I think that SignalAC calculation is also wrong...

Take a look at this code:

//--- first analyzed bar is "green" (the indicator has no objections to buying)
//--- if the second analyzed bar is "red", there is no condition for buying
   if(DiffAC(idx)<0.0) {

If the first bar is green and the second is red it stills return 90.0?


Joao Pedro Aguilera Cardoso  

Yeah, i've been thinking about the same problem.

"Am I getting crazy? Was that supposed to behave like the original code? How can we differentiate the "don't vote" from the real "0" (I mean, 0 stating for no condition for buying)"

As you can see here:

It seems that's the way different signals are weighted. The code multiplies the weight by the signal in the upper part of division, but doesn't consider it at the lower part of the division. So is not a normal average, nor a weighted one.

This looks so wrong to me.. If I'm backtesting I would like to give 0 weight to a sinal, and then see the signal disappearing of the signal chain.

I'm new to this (started trade a year ago, and a programming in mql5 yesterday) so I can be sounding nonsense here.

See ya

MQL5 Wizard: New Version
MQL5 Wizard: New Version
The MetaTrader 5 terminal continues to improve and acquire new features. The new MetaTrader 5 build 439 contains the updated MQL5 Wizard, which allows creating Expert Advisors based on more flexible trade rules. In this article we describe new possibilities of the MQL5 Wizard and explain the changes in the architecture of Expert Advisors...