[ARCHIVE] Any rookie question, so as not to clutter up the forum. Professionals, don't pass by. Nowhere without you - 3. - page 169

 

splxgf:

DhP:

How do you 'lighten up' this cycle? It takes a very long time to count.
 if(iHigh(NULL,60,i)>LOWprice && LOWprice>iLow(NULL,60,i)) if(LOWprice> bid) CountH++ else CountL++;

Or better still, like this:

 if(iHigh(NULL,60,i)>LOWprice) if(LOWprice>iLow(NULL,60,i)) if(LOWprice> bid) CountH++ else CountL++;

There's also the idea of generating an array of High and Low values. Maybe this will speed things up a bit?

 
abolk:


the order is selected https://docs.mql4.com/ru/trading/OrderSelect - looping or selecting by ticket

then the Order*() function looks up the relevant order parameter

Sorry for the blunt questions, but:

If we use MODE_HISTORY as the data source for selection in the OrderSelect function , i.e., the order is selected among closed and deleted orders, then how do we find the number of the order that was closed last? How are these orders numbered in the program? Is it from the last to the first or vice versa?

 
Xaoss1990:

Sorry, of course, for the stupid questions, but:

if the data source in the OrderSelect function is MODE_HISTORY, i.e. the order is selected among the closed and deleted orders, how do I find the number of the order that was closed last? How are these orders numbered in the program? Is it from the last to the first or vice versa?


there are many such questions on the internet

http://forum.alpari.ru/showthread.php?t=27708

 
Xaoss1990:

Sorry for the dumb questions, but:

if MODE_HISTORY is used in the OrderSelect function as the data source for selection, i.e. the order is selected among closed and deleted orders, how do I find the number of the order that was closed last? How are these orders numbered in the program? Is it from the last to the first or vice versa?


The function for finding the last of the closed ones is similar to the function for finding the order with the maximum closing time
 
LazarevDenis:


a lot of these questions have already been asked on the internet

http://forum.alpari.ru/showthread.php?t=27708

О! Found it, thanks:

OrderSelect(HistoryTotal()-1,SELECT_BY_POS,MODE_HISTORY);

That's right, isn't it?!

 
DhP:

How to "ease" this cycle? It takes a very long time to calculate.

Spellbound:

   INS = True;
   
   for (int i=1; i<=6000; i++)
   {
      if (INS)
      {
         if (LOWprice > iHigh(NULL,60,i))
         {
            INS = False;
            UPP = True;
            LOW = False;
            continue;
         }
         if (LOWprice < iLow (NULL,60,i))
         {
            INS = False;
            UPP = False;
            LOW = True;
            continue;
         }
      }
      else
      {
         if (UPP)
            if (LOWprice > iHigh(NULL,60,i))
               continue;
            else
            if (LOWprice < iLow (NULL,60,i))
            {
               // INS = "False"
               UPP = False;
               LOW = True;
               continue;
            }
         if (LOW)
            if (LOWprice < iLow (NULL,60,i))
               continue;
            else
            if (LOWprice > iHigh(NULL,60,i))
            {
               // INS = "False"
               UPP = True;
               LOW = False;
               continue;
            }
         
         INS = True;
      }
      
      if (LOWprice > Bid)
         CountH++;
      else
         CountL++;
   }

The logic is that price is more often outside historical bars than inside.

INS = Inside.

I checked accuracy of the code on a leaflet. I did not check the code speed. But I'm sure that boolean variables give a good advantage.

 
MaxZ:

Spellbound:

The logic is that price is more often outside historical bars than inside.

INS = "Inside".

P.S.: I checked the correctness of the code on a piece of paper. I did not check the code speed. But I'm sure boolean variables give a good advantage.


Yeah.

You must be so twisted to turn three clear lines of code into hard-to-understand code.

If you had the idea to split the iLow, iHigh check, you could have split it right away:

          if(LOWprice> bid)if(iHigh(NULL,60,i)>LOWprice)if( LOWprice>iLow(NULL,60,i))CountH++;  
          if(LOWprice<=bid)if(iHigh(NULL,60,i)>LOWprice)if( LOWprice>iLow(NULL,60,i))CountL++;
and don't fiddle with anything
 
      int HourPrices[20000];     
      for(int i=1; i<=6000; i++)
	 for (double cPrice=iLow(NULL,60,i);cprice<=iHigh(NULL,60,i);cPrice+=Point)
	  HourPrices[cPrice/Point]+=1;

Finding resistance levels from such an array is no problem. Add new bars and remove old ones at the same time. And fetching information from it is two cycles with one condition or ArrayMaximum will give the required value at once.

 
abolk:


Right.

You have to get so twisted as to turn three clear lines of code into code that is hard to understand.

If you had the idea of separating the iLow, iHigh check, you could have split it right away:

and don't mess around with anything

A similar variant to the one I suggested above (separating if's).

And you didn't even try to understand my idea (although I briefly described the logic)... When the price is high, we do one check instead of two. The same for the case when the price is low. And when price is within historical bars (which is quite rare - that's the logic and idea!), we do two checks (there is no other way).

The check is for price outside the bar, not inside. Earlier they were looking for a needle in a haystack, while I, if I don't see another needle, won't look for it either... The needle will show itself when it's needed! :)))

 
MaxZ:

A similar variant I proposed above (separate if's).

And you didn't even try to understand my idea (although I briefly described the logic)... When the price is high, instead of two checks we make one. The same for the case when the price is low. And when the price is within historical bars (which is quite rare - that's the logic and idea!), we do two checks (there is no other way).

         if (LOWprice > iHigh(NULL,60,i)) continue;
        if (UPPprice < iLow (NULL,60,i)) continue;
Your version can be reduced to these two lines added to the author's version, and with some modifications of the conditions should in principle be quite fast.
Reason: