Elite indicators :) - page 218

New comment
 

Mladen,

Thanks!

 

Mladen...

Hi Mladen,

RE: "nonlagma multi time frames trend" indicator

Looking at Line 164, I find this coding:

limit = MathMin(Bars-counted_bars,Bars-1);

Not being a coder, please forgive my ignorance. My question is whether this may be the reason for the indicator to jump back 2 bars even when set to 1 TF such as an M30 on M5-TF?

I see tremendous potential for this indicator, providing one can "rectify" this glitch.

Thank you for replying after enjoying the weekend.

Best regards.

 

ValeoFX

I must admit I do not understand your question completely, but will try to explain some things that I think are puzzling you.

_________________________

Metatrader treats arrays as C++ : when accessing a 10 element array last element, you do not use 10 for element index but 9. Hence the "Bars-1" part in that expression - to avoid exiting array boundaries. The first part (Bars-counted_bars) is simple determining how much bars did effectively change and needs to be calculated (every changed bar needs to be recalculated due to changed input) Since counted_bars can be 0, that expression can yield Bars as a number of bars to be calculated but then comes in the "Bars-1" safety.

That is all. It can not cause any wrong calculation. It is just determining how many bars should it recalculate (please do not fall into a trap that recalculating is repainting : it is not. As I said many times, repainting is a coding error, recalculating is a normal state of a code when with same inputs results must be the same too).

_________________________

The multi time frame on the other hand must be treated with care : it is a completely separate set of data, a completely separate number of bars changed, separate everything. That is the reason why I call the target time frame to get back the number of bars changed : otherwise it would be just an assumption. But when a target time frame is called it returns values that metatrader assigned and "knows" for that time frame, so no assumption is made. And when all the time frames number of bars are combined, the longest result must be use. But, as you know 1 hour bar on a 1 minute chart takes up to 60 bars for each 1 hour bar (I say "up to" since bars in any time frame can miss) hence every time frame bars number is multiplied with the ratio that represents the number of bars the target time frame occupies on a current chart.

So, a you see, it completely depends on the "answers" received from target time frames (metatrader terminal in the end) and target time frame calculations (again metatrader terminal and the number of recalculated bars) In my experience, metatrader tends to break some processes into smaller "chunks" : it distributes processing time between all the chart and all the threads it initiates and since every other time frame custom call is treated as a completely separate indicator and thread it might distribute that time "in his manner" (not sequentially for a process but sequentially for hist started threads which does not have to be the same as the processes order at all) and that might cause some "hick ups" at massive calculations - but as far as I know, in the end, it stabilizes and gives results that are correct, without any assumptions and without neglecting any part of the calculation as the whole, and is the goal of any correct calculation

_________________________

I hope that what I told here makes sense. I can not explain it simpler (teaching is not something I do good )

regards

Mladen

ValeoFX:
Hi Mladen,

RE: "nonlagma multi time frames trend" indicator

Looking at Line 164, I find this coding:

limit = MathMin(Bars-counted_bars,Bars-1);

Not being a coder, please forgive my ignorance. My question is whether this may be the reason for the indicator to jump back 2 bars even when set to 1 TF such as an M30 on M5-TF?

I see tremendous potential for this indicator, providing one can "rectify" this glitch.

Thank you for replying after enjoying the weekend.

Best regards.
 
mladen:
ValeoFX

I must admit I do not understand your question completely, but will try to explain some things that I think are puzzling you.

_________________________

Metatrader treats arrays as C++ : when accessing a 10 element array last element, you do not use 10 for element index but 9. Hence the "Bars-1" part in that expression - to avoid exiting array boundaries. The first part (Bars-counted_bars) is simple determining how much bars did effectively change and needs to be calculated (every changed bar needs to be recalculated due to changed input) Since counted_bars can be 0, that expression can yield Bars as a number of bars to be calculated but then comes in the "Bars-1" safety.

That is all. It can not cause any wrong calculation. It is just determining how many bars should it recalculate (please do not fall into a trap that recalculating is repainting : it is not. As I said many times, repainting is a coding error, recalculating is a normal state of a code when with same inputs results must be the same too).

_________________________

The multi time frame on the other hand must be treated with care : it is a completely separate set of data, a completely separate number of bars changed, separate everything. That is the reason why I call the target time frame to get back the number of bars changed : otherwise it would be just an assumption. But when a target time frame is called it returns values that metatrader assigned and "knows" for that time frame, so no assumption is made. And when all the time frames number of bars are combined, the longest result must be use. But, as you know 1 hour bar on a 1 minute chart takes up to 60 bars for each 1 hour bar (I say "up to" since bars in any time frame can miss) hence every time frame bars number is multiplied with the ratio that represents the number of bars the target time frame occupies on a current chart.

So, a you see, it completely depends on the "answers" received from target time frames (metatrader terminal in the end) and target time frame calculations (again metatrader terminal and the number of recalculated bars) In my experience, metatrader tends to break some processes into smaller "chunks" : it distributes processing time between all the chart and all the threads it initiates and since every other time frame custom call is treated as a completely separate indicator and thread it might distribute that time "in his manner" (not sequentially for a process but sequentially for hist started threads which does not have to be the same as the processes order at all) and that might cause some "hick ups" at massive calculations - but as far as I know, in the end, it stabilizes and gives results that are correct, without any assumptions and without neglecting any part of the calculation as the whole, and is the goal of any correct calculation

_________________________

I hope that what I told here makes sense. I can not explain it simpler (teaching is not something I do good )

regards

Mladen

=================

I bow to your superior knowledge, SIR!

Thanks for taking the time to teach me a valuable lesson. Much appreciated.

Wishing you a great week ahead.

 

Hi mladen

Could you please make a histo version of the nonlagdot indicator..

much appreciated

thank you.

Files:
nonlagdotalert.mq4  6 kb
 

Mike

Here you go Removed the ColorBarBack (no need at all for that parameter - redrawing that way was a leftover from a line drawing (not the dot drawing) mode)
regards

Mladen

mike pearce:
Could you please make a histo version of the nonlagdot indicator..

much appreciated

thank you.
 

THANK YOU MLADEN

 

nonlagdot indicator

have a request.

instead of having dots all over the chart, is it possible to draw an arrow up/down when color changes without drawing the dots?

this leaves the chart much cleaner and from my humble opinion is much more usfull in tring to evaluate it in "eye" backtasting.

does this indicator repaint?

thanks in advance,

Dada.

 

As i know it doesnt repaint..

 

Hi mladen

mladen:
Mike

Here you go

Removed the ColorBarBack (no need at all for that parameter - redrawing that way was a leftover from a line drawing (not the dot drawing) mode)
regards Mladen

I need to ask you one more favor

HISTO VERSION of Averages-mtf-alerts

Thank you for your time and patience

1...211212213214215216217218219220221222223224225...1519
New comment
Reason: