strange EA error

 

I have been running the same EA for 2 years. Once or twice in that time it has traded when all conditions were not met.

The latest was when Close[2] was lower than respective bollinger band level, when the condition statement ask for it to be higher than the band.

Has anyone come accross this?

It doesnt seem to show up in the tester.

The only thing can think of is the condition statement that had the band rule has 3 other conditions within the same statement:

 

        if(Close[i]>Open[i] && Close[i]>BB("up",i) && Reversal()==0){return(1);}

Can anyone confirm this, or suggest something?

 

Thank you

 

Antony 

 
Nope. Conditions at the time may-not be the same within the tester. You have all the codes and conditions. It falls upon you to place print statements around the algorithms in-order to track down the problem in the future.
 

1. This i, is it 0, 1, or 2 ?

2. When successfully send order, Print() the value of condition statement telling trading condition.

 

Hi

Thanks for the reply, basically i = 2.

The statement had to be satisfied for the the trade to be allowed, but when looking on the chart you can see the close[2] is not lower than the band.

Its almost like the EA skipped that statement :/

Thanks

 Antony 

 

1. I don't think this help much, but I try to avoid comparing string. You may want to change that "up" (or "down") into integer 1 (or -1), That way you comparing integer not a string.

2. Since the data was taken from bar number 2, maybe - just maybe - there are a hole in historical data (historical data is not complete). Read this article https://www.mql5.com/en/articles/1407 and use RefreshRates()

 
phi.nuts:

1. I don't think this help much, but I try to avoid comparing string. You may want to change that "up" (or "down") into integer 1 (or -1), That way you comparing integer not a string.

2. Since the data was taken from bar number 2, maybe - just maybe - there are a hole in historical data (historical data is not complete). Read this article https://www.mql5.com/en/articles/1407 and use RefreshRates()

I suspect BB is a function and "up" is a value passed to the function and the function then returns the Bolinger Band value . . .  ;-)
 
RaptorUK:
I suspect BB is a function and "up" is a value passed to the function and the function then returns the Bolinger Band value . . .  ;-)

Yeah maybe, Antony mentioned "the band" in his second comment. I just don't like comparing string - I think its taking too much memory in doing it than integer - it's my coding habit ;D.
 
phi.nuts:
Yeah maybe, Antony mentioned "the band" in his second comment. I just don't like comparing string - I think its taking too much memory in doing it than integer - it's my coding habit ;D.

Ah I see your point now . . .  you mean in the function that uses the string,  of course,  good point,  I'll bear that in mind,  thanks.  :-)   could just as easily use a defined constant . . .

#define UP   1
#define DOWN 2

BB(UP,i)


double BB(int direction, int Index)
   {
   if direction == UP
      {
      ......
      }
   }
 
RaptorUK:

Ah I see your point now . . .  you mean in the function that uses the string,  of course,  good point,  I'll bear that in mind,  thanks.  :-)   could just as easily use a defined constant . . .

Ah yes, just another of my coding habit, I never use #define.

I should get readable-coding-habit right ? 

Thanks for being reminder :D

 

Hi

Thanks for your comments.

Had had stringS used a lot in my EA now I have recoded to use integers. So string use more resourses when processing the EA? I wonder if the mishap was caused by an overload on resources? I do have quite a lot of charts running at once with the same EA.

 

Thanks

 

Antony 

 
tonyjms2005:

Hi

Thanks for your comments.

Had had stringS used a lot in my EA now I have recoded to use integers. So string use more resourses when processing the EA? I wonder if the mishap was caused by an overload on resources? I do have quite a lot of charts running at once with the same EA.

 

Thanks

 

Antony 

I don't think string is the cause of your problem, but hole/incomplete/corrupt historical data may be the cause.

Rather than using string, it's not bad idea to use #define - see RaptorUK's comment above. I just think that string takes too much memory, that's all.

Reason: