Front of indicator problem

New comment
 

Can anybody see the problem in my indicator. I am sure it is something to do with the limits of the arraysbut I can't see what. When I put the indicator on the chart it is correct but as the ticks come in it goes to pot on the front end. I don't want to use indicator buffers for the arrays Emabuf & Demabuf because I want to use the indicator lines for some arrows and other signals later. If these arrays are set as indicator buffers everything works correctly but when they are set as internal arrays the line gets screwed up at the front.

Thanks

Files:
tworm.mq4  3 kb
 
Ruptor:

Can anybody see the problem in my indicator. I am sure it is something to do with the limits of the arraysbut I can't see what. When I put the indicator on the chart it is correct but as the ticks come in it goes to pot on the front end. I don't want to use indicator buffers for the arrays Emabuf & Demabuf because I want to use the indicator lines for some arrows and other signals later. If these arrays are set as indicator buffers everything works correctly but when they are set as internal arrays the line gets screwed up at the front.

Since no-one else seems to be replying... I think you may have two distinct problems:

  • You're storing the bar range (* 10000) in bdif. On the first call to the indicator, limit will be a very large value and bdif gets populated with the ranges for the full bar history. On subsequent calls, limit is a value such as 2 and only the last couple of bdif values are recalculated. But when a new bar starts, the old values in bdif are not shunted backwards. Therefore, the new bar gets put into bdif[0], overwriting the data for the bar which was previously there. That seems to be why, after a new bar starts, some of the historic values shown by the indicator no longer quite seem to tally with the values displayed by a brand new instance of the indicator. For example, at outset bdif[0 to 6] hold the ranges for bars G to A. When a new bar H starts, limit is a value such as 2. Therefore, bdif[0] gets set to H, bdif[1] gets set to G, and bdif[2] gets set to F. The bar values in bdif[0 to 6] are now HGFDCBA. E has gone missing.
  • If Emabuf and Demabuf are not indicator buffers, then their contents are not static across calls to start(). On all calls to the indicator after the first one, limit is a value such as 2. Therefore, only Emabuf[2], Emabuf[1], and Emabuf[0] get populated. Emabuf[3] onwards are zero. You then try to do a moving average of something like the last seven values of Emabuf. That would explain why the indicator line always seems to fall when new ticks come in: zeroes are being included in the moving average calculations.

 

Hi jjc

I have done a couple of tests on your suggestions but can you clarify one point. If I declare variables just beneath the external parameters so they are global to init and start they hold their value between calls are you saying arrays do not?

In the first test I made the arrays static but no difference. in the second test I set limit=1000 and the graph turned in to a flat line. I was thinking that the arrays don't need to be static because they are written anew on every tick and then the penny dropped about what you said about the value of limit being 2 so I made it that the arrays would only be resized once on the first tick. the indicator seems to work now but I don't understand why. I have a fixed value of limit=1000 so when the penny dropped I don't think it reached the bottom. If the limit is fixed and the arrays are set anew on every tick how come resizing the array on every tick dosen't work?

Thanks for the help so far.

 
Ruptor:

Hi jjc

I have done a couple of tests on your suggestions but can you clarify one point. If I declare variables just beneath the external parameters so they are global to init and start they hold their value between calls are you saying arrays do not?

Sorry, that bit was complete nonsense. I don't know what I was thinking of. Of course the values get preserved.

 
Ruptor:

in the second test I set limit=1000 and the graph turned in to a flat line [...] Ihave a fixed value of limit=1000 so when the penny dropped I don't think it reached the bottom. If the limit is fixed and the arrays are set anew on every tick how come resizing the array on every tick dosen't work?

That's a good question, and not one which I have a full answer to. It's something to do with iMAOnArray not liking arrays with uninitialized members.


If you set limit = 1000, then the problem seems to come with the calculation of the moving-average of the moving-average - i.e. Demabuf. With limit set to a fixed value, try adding the following line immediately after the calculation of the Emabuf values:


Comment("Emabuf[0]: " + Emabuf[0] + " MA[0] on Emabuf: " + iMAOnArray(Emabuf, limit, MAPeriod, 0, MAType, 0));


For me, this is confirming that Emabuf[0] (and [1] and [2] etc) are non-blank, but the average being returned is very near zero (but not exactly zero - try comparing the return value from iMAOnArray with zero).


The code does work if you initialize the size of Emabuf and Demabuf to be whatever the fixed size of limit is, rather than Bars. To me, this implies that there's some issue with iMAOnArray() if some members of the array haven't been initialized. May perhaps be working in combination with the fact that you're filling e.g. Emabuf[0 to 1000], and then trying to do a moving average starting at position 1000 - i.e. getting the average of items 1000 through 1000+MAPeriod.

 

Hi jjc

Well at least the indicator is working now even if there is issues with iMAOnArray. I couldn't grasp why the front end of the indicator would be getting screwed up at the front elements when any duff data should have been at the back end. To my mind it should have sorted itself out after the first 50 points. When the indicator is used in the EA I will only be interested in the values over the MA period anyway.

Thanks for the help.

 

Hi Guys

There is a big problem in indicators with the use of arrays that causes the indicator to slow everything down. If I use just the latest 1000 elements of a buffer instead of the complete buffer the indicator runs exceedingly slow. On the backtester optimising 2 variables takes 6 hours by using only 1000 array elements but only 10 minutes when the all of the buffers are used. There is no error during compilation or running so what is going on?

New comment
Reason: