Why does 'for' loop, only loop approx 250 times?

 

If i place either of these scripts on a M1 chart, with thousands of bars loaded - they both begin counting aproximately 250 numbers from the end. (i.e. they start at 250 & 150 respectively), & then count through to the end (400 or 500 respectively. The beginning number is normally not exactly the same, but is always approximately 250.

Why does this happen? And how can i increase the loop to count a full day of M1 bars (approx 1500).



int start()

{
for(int Counter=1;Counter<500;Counter++)
{
Print("Counter is ",Counter," of 500");
Counter++;
}
}


int start()

{
int Counter=1;
while(Counter<400)
{
Print("Counter is ",Counter," of 400");
Counter++;
}
}
 

You're not doing the for loop correctly, you are incrementing the counter in the loop header and then again at the end of the loop you only need to do that one time, it should be like this

for(int Counter=1;Counter<500;Counter++)
 {
  Print("Counter is ",Counter," of 500");
 }

I'm assuming you have other code to make your script count bars from the history chart, there is 1440 minutes in a day so just increase the loop to count that many bars

 
SDC:

You're not doing the for loop correctly, you are incrementing the counter in the loop header and then again at the end of the loop you only need to do that one time, it should be like this

I'm assuming you have other code to make your script count bars from the history chart, there is 1440 minutes in a day so just increase the loop to count that many bars

Thanks for the reply. I accidently left the Counter++ line in the body of my code when modifying the 'while...' version when I made the post to this forum.

Ive corrected the code as you suggested, and the same result (except this time commences at no 299 & runs to no 500.

Any further ideas?

 
Solarent:

Ive corrected the code as you suggested, and the same result (except this time commences at no 299 & runs to no 500.

It looks like the code is working correctly, but the results aren't getting logged in full because the volume is overwhelming MT4 and it's discarding log entries. If you want to check this, replace Print() with MessageBox(). And be prepared to keep holding down the Esc key...

One further issue is that there aren't necessarily 1440 (24 x 60) M1 bars in a day. If your broker didn't have any ticks for the symbol during a minute then there won't be an M1 bar, and looping through 1440 bars will take you back more than 24 hours.

 
jjc:

It looks like the code is working correctly, but the results aren't getting logged in full because the volume is overwhelming MT4 and it's discarding log entries. If you want to check this, replace Print() with MessageBox(). And be prepared to keep holding down the Esc key...

One further issue is that there aren't necessarily 1440 (24 x 60) M1 bars in a day. If your broker didn't have any ticks for the symbol during a minute then there won't be an M1 bar, and looping through 1440 bars will take you back more than 24 hours.


Thankyou, Ive done as you suggested and after getting a sore finger - the code ran through 300 loops (the number I coded - my finger wont last more than that!), & it didnt miss one. It would seem it runs through the first loops very quickly and depending on processor load, it begins slowing and has time to 'print' the result - hence the variance in the commencing number. Accordingly i retried the 'for loop' to a counter of 1500, with a 'print' output. And if what i suspected was correct, I would have expected the first 'print' in the log would be around 250-300 out of 1500. i.e. as the processor loaded up it would begin printing to the log. BUT ran the code and the first 'print' in the log was 1274 of 1500. again approx 250 from the end.

Thanks for the advice re no of bars in a day, but the loop uses a datetime variable to select the correct one, to avoid that problem.

 
Solarent:
It would seem it runs through the first loops very quickly and depending on processor load, it begins slowing and has time to 'print' the resul
Being pedantic, the logging is asychronous, and in cases such as this keeps getting spooled to the visual display long after the code has finished running. I'd guess that there's some internal display buffer which doesn't start getting monitored and processed until slightly after the code has started running. Therefore, if the code fills the buffer immediately, entries are going to get discarded. But that's purely a guess.

You should find that the log file in experts\logs contains all the entries. I should perhaps have mentioned this before suggesting that you hold down the Esc key for several hundred iterations.
 
jjc:
Being pedantic, the logging is asychronous, and in cases such as this keeps getting spooled to the visual display long after the code has finished running. I'd guess that there's some internal display buffer which doesn't start getting monitored and processed until slightly after the code has started running. Therefore, if the code fills the buffer immediately, entries are going to get discarded. But that's purely a guess.

You should find that the log file in experts\logs contains all the entries. I should perhaps have mentioned this before suggesting that you hold down the Esc key for several hundred iterations.


Great thankyou. Checked the log and indeed 1500 of 1500 counter entries. So why it displays the log as it does is possibly as you suggested. Though confusing, the important thing is it runs correctly. Thanks for your guidance.
 

Here is an alternative for Print() that is much much more usable and does not become "overwhelmed" by the amount and does not arbitrarily forget to log things.

http://www.forexfactory.com/showthread.php?t=245303


Its sending the messages to a running system debug monitor (for example DebugView.exe) where you can easily watch them in realtime, filter them, log them to disk, have exact (10 milliseconds) timestamps (for profiling the code), etc.

I use it a lot, and also when writing/using DLLs this is very handy, I let them all output their debugging info to OutputDebugStringA() because a running mt4 has no stdout to print to and so I have all my output from EA and DLL in one place and in the correct order.

 
Dude this link is awesome! Thanks.
 

can someone help me edit sar ohlc to use heiken ashi ohlc

Hi, I have an MTF indicator that uses sar, however I'd like the sar to calculate heiken ashi ohlc, and not the normal type

Can you tell me how I can do this, my mtf indicator calls to the sar indicator to calculate sar formula, I think it is calling to the internal indicator in mt4 that can not edit

you can skype or email if you can assist and like to talk about it

skype sty671

email sty671@gmail.com

I can also supply the original file that I'm trying to use heiken ashi ohlc for

Reason: