Strategy Tester Gets Stuck

New comment
 

Attaching here is the code of a simple EA that am trying to write based on SMA

but while testing it on strategy tester, the tester opens an order and gets hanged.

Plz help.

Files:
ea01.mq4  4 kb
 

Hi Jay,

when coding you should stay away from while loops as much as possible. They go easily into an endless loop. I guess that's the problem too in this EA.


hth

 

Russell wrote >>

when coding you should stay away from while loops as much as possible. They go easily into an endless loop.

Respectfully, I disagree. In certain cases using 'while' loops makes for much better clarity than forcing a 'for' loop when it's not needed. 'Endless loop' bugs can happen with 'for' loops as well...

  
  while(Buy == true) {
         while(OrdersTotal() < 1) {
               StopLoss = Low[iLowest(Symbol(), 0, MODE_LOW, 4, 0)] - AverageTR / 2.0;
               OrderSend(Symbol(), OP_BUY, 0.10, NormalizeDouble(Ask,4), 3, NormalizeDouble(StopLoss,4), 0,0,0,0);   
               Alert("The Last Error " , GetLastError());
               break;
            }
      }

while(Buy == true) is redundant, simplify while(Buy)...

You are trying to open an order when buy is true.

1) you don't test if orderSend succeeded or not

2) the break takes you out of the inside loop, but not out of the outside loop, therefor infinite loop.

Drop the loops

if (Buy && OrdersTotal() == 0) { // SL=...
 
WHRoeder:

while(Buy == true) is redundant, simplify while(Buy)...

You are trying to open an order when buy is true.

1) you don't test if orderSend succeeded or not

2) the break takes you out of the inside loop, but not out of the outside loop, therefor infinite loop.

Drop the loops


Thanks, I will change the code and try to back test!
 
gordon:

Respectfully, I disagree. In certain cases using 'while' loops makes for much better clarity than forcing a 'for' loop when it's not needed. 'Endless loop' bugs can happen with 'for' loops as well...

I didn't say never use while loops, just stay away from them if they aren't really needed. By forcing a for loop to do a while task you're obviously heading in the wrong direction. Sure you can get a for loop into an endless one, but it takes a bit more effort. 8-)

btw i don't think while(Buy == true) more complex than while(Buy). In my opinion every condition should be tested, a boolean preferably to false: while (lbBuy != FALSE)

 

Use of proper bool variable names makes the code clearer:

I prefer
versus
while(Buying) {buy code...}
while(ibBuy != false) {...}
if(!Buying) {sell code...}
if(ibBuy != true) {//sell code
bool RRRok = (TP-Ask)/(Bid-SL) > RRR.min;
bool Buying = EMA5 > EMA13;
if (Buying && RRRok) {buy code...}
if ( (TP-Ask)/(Bid-SL) > RRR.min
&& EMA5 > EMA13) {buy code...}
 
WHRoeder:

Use of proper bool variable names makes the code clearer:

I prefer
versus
while(Buying) {buy code...}
while(ibBuy != false) {...}
if(!Buying) {sell code...}
if(ibBuy != true) {//sell code
bool RRRok = (TP-Ask)/(Bid-SL) > RRR.min;
bool Buying = EMA5 > EMA13;
if (Buying && RRRok) {buy code...}
if ( (TP-Ask)/(Bid-SL) > RRR.min
&& EMA5 > EMA13) {buy code...}

I agree with Roeder...why to do double check
 

I agree that proper variable names make code clearer, but the conditions easily get scattered over the code this way. So it will become harder to debug.

In my opinion "Buying" isn't a correct var name. I use a coding standard which helps me easily track and control dozens of vars if needed. I never have to guess what will be affected, or what will break if I put the wrong values in a var. So that is WHY you have to check your var at the decision point. A var could have been changed some where in your code unintended.

Example

int start(){

   int Buying = TRUE;

   // a lot of code
   Buying++;
   // a lot of code   
   Buying/=10;

   //decision point
   if (Buying){
     OrderSend(....);
   }
}  

ok not the best example, but the best I could come up with. The code is valid but could give very unexpected results. 

int start(){

   int liBuying = 1;
   bool lbBuying = TRUE;

   // a lot of code
   liBuying++;
   // a lot of code   
   liBuying/=10;

   //decision point
   if (lbBuying != FALSE){
     OrderSend(....);
   }
} 


/*

prefix
-------
g - global var
r - return var
l - local var
_ - input var
s - static var

second letter var type
------------
i - int
d - double
s - string
b - bool

followed by a clear name in camelCaps

*/

int    giTrailing = 100;
string gsTrailing = "Trailing Stop";
double gdTrailing[2];

void stateTrailing(int _iTrailing, double &rdTrailing[]){

   bool lbTrailing = FALSE;
   static bool sbTrailing = FALSE;

   if (lbTrailing == sbTrailing){
      rdTrailing[0] = _iTrailing/0.15;
   } 
}
 
Russell:

[...] By forcing a for loop to do a while task you're obviously heading in the wrong direction.

I agree and that's what I meant. U should use a 'while' loop when its the best choice; use a 'for' loop when it's the best choice. I was just referring to 'when coding you should stay away from while loops as much as possible'. IMHO, they should not be avoided; they should be used properly when they are the 'best' choice.

 
WHRoeder:

Use of proper bool variable names makes the code clearer

That's a matter of opinion and coding style. Although there is a slight performance impact in doing it Russel's way (it's slightly slower - but almost negligibly so)...
123
New comment