ForumSections

How can I iterate an indicator from past to present? - page 2

New comment

Good afternoon everyone,

Thanks for your answers. I'll be more specific. My bar iteration is as follows and it iterates from present to past.

int start()
  
    // Start, limit, etc..
    int start = 0;
    int limit;
    int counted_bars = IndicatorCounted();

    // check for possible errors
    if(counted_bars < 0) 
        return(-1);

   //last counted bar will be recounted
    if(counted_bars > 0) 
        counted_bars--;
      
    // Only check these
    limit = Bars - counted_bars;
   
    // Check the signal foreach bar
    for(int i = start; i < limit; i++)
    {     
        // Blabla
    }
}

Now, my problem is throwing lots of consecutive signals of the same type, but since I am iterating from present to past, I can only use iCustom() recursively to know past signals and it is really disfunctional since I don't have access to other critical data not stored in buffers. Can I iterate from past to present in such a way that the indicator works properly in real time?

Cheers!

Why not rewriting the code to iterate from past to now? If this is not possible you have a calculation problem and are probably looking into the future, so unless you want to code a repainter, this is the wrong way to go.

Once you iterate correct you can simply access your already filled buffers and you have no problems with recursive?

BTW, calling icustom() does not work for you since your code would be trapped in a endless loop. Your called icustom would need to call icustom again, and again and again to verify the signal..

flaab:. I'll be more specific. My bar iteration is as follows and it iterates from present to past.

Now, my problem is throwing lots of consecutive signals of the same type, but since I am iterating from present to past, I can only use iCustom() recursively to know past signals.

So the indicator has done its job and drawn lots of stuff, regardless of the direction it is done in. That has nothing to do with iCustom at all. iCustom can now pick any value in the history of the indicator.

At the risk of sounding rude it sounds as though you have mis-understood the definition of recursively. Why would iCustom need to call iCustom? Did you perhaps mean call iCustom repeatedly ( a VERY different concept). If you do mean recursive as in "DEFINITION of RECURSION: calling itself, see recursion" then please try to explain why.

dabbler:

So the indicator has done its job and drawn lots of stuff, regardless of the direction it is done in. That has nothing to do with iCustom at all. iCustom can now pick any value in the history of the indicator.

At the risk of sounding rude it sounds as though you have mis-understood the definition of recursively. Why would iCustom need to call iCustom? Did you perhaps mean call iCustom repeatedly ( a VERY different concept). If you do mean recursive as in "DEFINITION of RECURSION: calling itself, see recursion" then please try to explain why.

Hello Dabbler,

For each signal that my indicator throws, it checks the last N bars to avoid repetition. And all those calls check the last N bars as well to avoid repetition and so forth. It sounds like recursion to me -it's like a function calling itself over and over again-. It is not an infinite loop but it definetely seems easier to iterate from past to present :) You are not rude, don't worry.

flaab:

Hello Dabbler,

For each signal that my indicator throws, it checks the last N bars to avoid repetition. And all those calls check the last N bars as well to avoid repetition and so forth. It sounds like recursion to me -it's like a function calling itself over and over again-. It is not an infinite loop but it definetely seems easier to iterate from past to present :) You are not rude, don't worry.


It should be an infinite loop, since on the call to icustom() the indicator does the same thing as your initial indicator (exept you make a extern int startinpoint;) But on a M1 chart with 100000 bars this can cause a big performance drop, and you most likely do not want that
zzuegg:

Why not rewriting the code to iterate from past to now? If this is not possible you have a calculation problem and are probably looking into the future, so unless you want to code a repainter, this is the wrong way to go.

Once you iterate correct you can simply access your already filled buffers and you have no problems with recursive?

BTW, calling icustom() does not work for you since your code would be trapped in a endless loop. Your called icustom would need to call icustom again, and again and again to verify the signal..

Exactly, storing variables just "looks into the future" and makes the code useless, so I am not doing it and instead I am "looking into the past" with iCustom() but it is very unnefective.

I will iterate from past to present, any examples you might have at hand? Thank you.

The most simple solution:

This allows to generate one signal per direction without any lookbackloop.

//add: you have to implement a function:

int getSignal(int i){
 calculate the signal for bar i, return 1 on buysignal, return -1 on sellsignal
}
for(int i=Bars-counted_bars-1;i>=0;i--){
 static int currSignal=0;
 if(getSignal(i)==1 && currSignal!=1){
   //draw buy signal
   currSignal=1;
 }
 if(getSignal(i)==-1 && currSignal!=-1){
   //draw sell signal
   currSignal=-1;
 }
}
zzuegg:

The most simple solution:

This allows to generate one signal per direction without any lookbackloop.

//add: you have to implement a function:

Thanks a million zzuegg. It seems this scheme iterates from past to present and allows new signals to be painted, is that right? I hope I can be useful to you in the future as you are to me now. 
 //last counted bar will be recounted
    if(counted_bars > 0) 
        counted_bars--;
      
    // Only check these
    limit = Bars - counted_bars;
   
    // Check the signal foreach bar
    for(int i = start; i < limit; i++)
The decrement is unnecessary
 //last counted bar will be recounted
//    if(counted_bars > 0) 
//        counted_bars--;
      
    // Only check these
    limit = Bars -1 - counted_bars;
   
    // Check the signal foreach bar
    for(int i = limit; i >= 0; i--)
WHRoeder:
The decrement is unnecessary

OK, all has been sorted out according to WHRoeder and Zzuegg. Here is the result. Iterates from past to present.

int start()
  {
    // Start, limit, etc..
    int start = 0;
    int limit;
    int counted_bars = IndicatorCounted();

    // check for possible errors
    if(counted_bars < 0) 
        return(-1);

    // Unnecesary ?
    // if(counted_bars > 0) 
    //    counted_bars--;
      
    // Iteration limit
    limit = Bars - 1 - counted_bars;
    
    // Check if ignore bar 0
    if(CalculateOnBarClose == true) start = 1;
    
    // Check the signal foreach bar
    for(int i = limit; i >= start; i--)
    {
    }
}
12
New comment