It has some coding errors in it. One of the errors will cause it not to show the value at all for every new bar. Some others are not that heavy but they needed to be corrected. Also a limitation it had with maximum calculating length is removed in this one. So posting a cleaned up and simplified one here

And while at it, since they had quite a flaming dispute at that thread (the one referenced in the code : Диалог автора. Александр Смирнов. - MQL4 форум ) made the "Quadratic Regression MA" as defined there by "mathemat" (qwma is a part of "Quadratic Regression MA")

So here are 2 : qwma (a variation of linear weighted moving average (different weight coefficients) - violet) and qrma (Quadratic Regression moving average - blue)

Thank you vey much Mladen,it is hard to understand the dispute between them with google translator.Mladen is it possible to add shift function?

Second thing FIR MA has this 10 bar lag FIR MA - MQL4 Code Base ,is it possible fill that 10 bar with your nonlagMA ?I have seen similar idea with HP , removing the recalculation with HMA : geHMA_HP - MQL4 Code Base

The perfect solution exist, but ... as usual, there is always a but _____________________

Let me start this way :

What qpwr did there is actually centering - if one does it by shifting result values or using already shifted values in calculation, it does not matter. The result is the same : it leaves a portion of values "unknown". And then they must be "invented" - by extrapolation or any other way. Non lag ma or any other ma can be added there (as in the Hodrick/Prescott filter) but then you are getting a sort of a calculating Frankenstein. Whatever way is used, it is a subject to change and it will change (those are 2 different calculations - hull is not and can not be HP), hence I do not think that it is a logical way to do it (it is breaking the logic of the indicator - patching 2 in 1)

Now, centering is one of the ways people are trying to eliminate lag ...

_____________________

The other way is "the perfect way"...

Idea is as simple as it gets. When you calculate an average, filter, whatever "from left to right" you are adding lag. Why not calculating the result you get once again but now from "right to left" and adding negative lag in that case, and getting as a result, no lag at all. No "zero lag" in names, nothing that fancy, but that average simply does not have lag. Regardless of the calculation period, regardless of the calculation method ...

As an example : here is a "perfect" no lag at all linear weighted moving average (violet) compared to regular LWMA (black). Not only that there is no lag but it is much smoother too (simply because it is 2 times smoothed) Calculating period of the regular LWMA is 2 times the calculating period of the "no lag at all" one (even though it is not a completely fair comparison regarding the "no lag at all" one in this case, but it does not matter now)

And now comes the "but" : it repaints the last calculation period bars the same as any other centered and extrapolated, centered and patched, or any other method that is trying to eliminate lag. But we must admit : it sure looks good

biddick: Thank you vey much Mladen,it is hard to understand the dispute between them with google translator.Mladen is it possible to add shift function?
Second thing FIR MA has this 10 bar lag FIR MA - MQL4 Code Base ,is it possible fill that 10 bar with your nonlagMA ?I have seen similar idea with HP , removing the recalculation with HMA : geHMA_HP - MQL4 Code Base

The reason : as I explained in that post (this post : https://www.mql5.com/en/forum/general ) the calculation direction of it is "from left to right". If it is changed and if all the rest of coding stuff that needs to be changed is changed, you are not going to get anything similar to the SHI trend silver. It is a very similar case to 3 ema crosses which when the direction is inverted becomes in effect a sort of MACD.

I thought that the post I posted was explanatory If you take a look at the signals you will see that they are almost all wrong if the calculation is done from right to left (if one would take the signals given by big dots, it would clean the account in no time). I can correct when something has en error, but I can not transform something to be correct and to give same signals as the repainting and wrongly coded one. There is no "correct" SHI trend signals indicator - when everything is "corrected" what you get is what is shown on that picture

regards

Mladen

Tradefx1: mladen,
many thanks for correcting the Shi trend silver

Thanks

Thanks Mladen:)

Mladen,

You never cease to amaze me!

Thanks for sharing.

Cheers,

Some funny indicators( it looks like there are some advance math and coding in them) I collected from Russian forums.

Files:biddick

About one of the indicators attached : the M_qwma

________________________

It has some coding errors in it. One of the errors will cause it not to show the value at all for every new bar. Some others are not that heavy but they needed to be corrected. Also a limitation it had with maximum calculating length is removed in this one. So posting a cleaned up and simplified one here

And while at it, since they had quite a flaming dispute at that thread (the one referenced in the code : Диалог автора. Александр Смирнов. - MQL4 форум ) made the "Quadratic Regression MA" as defined there by "mathemat" (qwma is a part of "Quadratic Regression MA")

So here are 2 : qwma (a variation of linear weighted moving average (different weight coefficients) - violet) and qrma (Quadratic Regression moving average - blue)Files:Thank you vey much Mladen,it is hard to understand the dispute between them with google translator.Mladen is it possible to add shift function?

Second thing FIR MA has this 10 bar lag FIR MA - MQL4 Code Base ,is it possible fill that 10 bar with your nonlagMA ?I have seen similar idea with HP , removing the recalculation with HMA : geHMA_HP - MQL4 Code Base

Files:Ahhhh, the eternal lag problem

The perfect solution exist, but ... as usual, there is always a but _____________________

Let me start this way : _____________________The other way is "the perfect way"...

Idea is as simple as it gets. When you calculate an average, filter, whatever "from left to right" you are adding lag. Why not calculating the result you get once again but now from "right to left" and adding negative lag in that case, and getting as a result, no lag at all. No "zero lag" in names, nothing that fancy, but that average simply does not have lag. Regardless of the calculation period, regardless of the calculation method ...

As an example : here is a "perfect" no lag at all linear weighted moving average (violet) compared to regular LWMA (black). Not only that there is no lag but it is much smoother too (simply because it is 2 times smoothed) Calculating period of the regular LWMA is 2 times the calculating period of the "no lag at all" one (even though it is not a completely fair comparison regarding the "no lag at all" one in this case, but it does not matter now) And now comes the "but" : it repaints the last calculation period bars the same as any other centered and extrapolated, centered and patched, or any other method that is trying to eliminate lag. But we must admit : it sure looks goodbiddick:Thank you vey much Mladen,it is hard to understand the dispute between them with google translator.Mladen is it possible to add shift function? Second thing FIR MA has this 10 bar lag FIR MA - MQL4 Code Base ,is it possible fill that 10 bar with your nonlagMA ?I have seen similar idea with HP , removing the recalculation with HMA : geHMA_HP - MQL4 Code Base

Files:Podrias identificar y enviarme la pagina wed de los indicayores que estan "On chart"

Podrias identificar y enviarme los indicayores o la pagina wed de los indicayores que estan "On chart"

Files:Alert on DTosc_Smoothed

Mladen,

Please would you be kind enough to add an audible Alert on the "#DTosc & Arrows - smoothed" for me?

Similar to #DTosc - arrows & alerts" which you very kindly made for me a while back.

Thanking you most sincerely.

Files:Shi trend Silver

mladen,

many thanks for correcting the Shi trend silver

Tradefx1

As far as I remember I did nothing of a sort

The reason : as I explained in that post (this post : https://www.mql5.com/en/forum/general ) the calculation direction of it is "from left to right". If it is changed and if all the rest of coding stuff that needs to be changed is changed, you are not going to get anything similar to the SHI trend silver. It is a very similar case to 3 ema crosses which when the direction is inverted becomes in effect a sort of MACD.

I thought that the post I posted was explanatory If you take a look at the signals you will see that they are almost all wrong if the calculation is done from right to left (if one would take the signals given by big dots, it would clean the account in no time). I can correct when something has en error, but I can not transform something to be correct and to give same signals as the repainting and wrongly coded one. There is no "correct" SHI trend signals indicator - when everything is "corrected" what you get is what is shown on that picture

regards

Mladen

Tradefx1:mladen, many thanks for correcting the Shi trend silver