Indicators: Corr average

 

Corr average:

Average using dr. Andreas Uhl's "correction method.

Author: Mladen Rakic

 

Many thanks for generously sharing the many Indicators here on the CodeBase section!

Would it be possible, for you to provide a reference link to the "correction method" developed by Dr. Andreas Uhl that you have used here (and on some other Indicators you have shared)?

I have done a search on the Internet and have found many of his publications, but I didn't find any title that hinted to it being about his "correction method" (unless it is buried in one of those publications mentioned).

 
Fernando Carreiro:

Many thanks for generously sharing the many Indicators here on the CodeBase section!

Would it be possible, for you to provide a reference link to the "correction method" developed by Dr. Andreas Uhl that you have used here (and on some other Indicators you have shared)?

I have done a search on the Internet and have found many of his publications, but I didn't find any title that hinted to it being about his "correction method" (unless it is buried in one of those publications mentioned).

The list of all his publications (many of those can be downloaded) can be found here : http://wavelab.at/member-uhl.shtml
Multimedia Signal Processing and Security Lab
  • mgschwan
  • wavelab.at
About Me: I am a Full Professor at the Department of Computer Sciences, University of Salzburg, Austria. I hold Master degrees in Pure Mathematics as well as Secondary/High School teacher education (with qualifications for mathematics, computer science, philosophy, and psychology), a PhD in applied mathematics, and I am tenured for computer...
 
Mladen Rakic:
The list of all his publications (many of those can be downloaded) can be found here : http://wavelab.at/member-uhl.shtml
Yes, I know that and I even stated that in my post. I just need to know which one, has reference to the "correction method" that you have used here in your indicators.
 
Fernando Carreiro:
Yes, I know that and I even stated that in my post. I just need to know which one, has reference to the "correction method" that you have used here in your indicators.
http://www.buero-uhl.de/papers.htm
 
Thank you!
 

May I ask you what you personally think about Ahl's correction?

I have created a mt4-indicator with an ema (dotted, aqua) and a dema (dotted, yellow) with the same period=14 and applied to the ema the normal stddev to get Ahl (solid, aqua) and the incremental stddev (solid, yellow - thanks to Fernado!) to the dema.

On one hand it is quiet impressive that in a flat market Ahl becomes perfect horizontal - but on the other hand it is lagging very much when a market goes flat!

What are your thoughts about this?

Calli

Ahl on Ema and Dema

PS: Ahl uses this
v2/(v1+v2)
but you are using
1-v1/v2 (which I found in a different forum)
 
Carl Schreiber:

May I ask you what you personally think about Ahl's correction?

I have created a mt4-indicator with an ema (dotted, aqua) and a dema (dotted, yellow) with the same period=14 and applied to the ema the normal stddev to get Ahl (solid, aqua) and the incremental stddev (solid, yellow - thanks to Fernado!) to the dema.

On one hand it is quiet impressive that in a flat market Ahl becomes perfect horizontal - but on the other hand it is lagging very much when a market goes flat!

What are your thoughts about this?

Calli


PS: Ahl uses this

I am afraid I do not know who "Ahl" is ...

In any case you are missing the loop part in what you are trying to compare (in the original method you have to check the next few lines too), this part :

{calculate current gain factor K}
e=1;
Kold=1;
while e>tol begin
        K=v3*Kold*(2-Kold);
        e=Kold-K;
        Kold=K;
end;    

and you can not do that (if you omit that loop part in the original method, then you are missing the whole point and then you are comparing the in-comparable)

Anyway : the modification/correction to Uhl's method was made in order to allow that method to :

  • be more CPU efficient
  • be usable on any set of values (without a need to set some minimal gain)
  • since more or less the gain is quite similar in both cases (methods) of calculation - except with the above described reasons for change, I do believe that the method I am using is usable on any set of values (unlike the original method) regardless of their range of values

Also, I do not understand the point about lagging. The whole point about "correcting" is to filter out the not-necessary noise : ie. to lag (if you want to call it that way)

And again : you can not compare ema to dema. They are completely different things. Any comparison disregarding the fact that dema is so different from ema (by it's nature) is leading to a wrong conclusion

 
Carl Schreiber: ... and the incremental stddev (solid, yellow - thanks to Fernado!) to the dema ...

Carl, the specific "incremental calculation of a weighted variance" that I shared previously, can only be applied to EMA (not DEMA). So, be careful of not mixing "apples" and "oranges" here (unless I am misunderstanding your post, and you are referring to the EMA calculations you use to build the DEMA and not the variance of the final DEMA value).

For those reading this post and not aware about the "calculation" in question, here is the reference to post in question:

Forum on trading, automated trading systems and testing trading strategies

[Help] What is the Real Formula of Exponential Moving Average? Please explain it to me. I searched in internet, I found many EMA Formula.

Fernando Carreiro, 2016.12.12 22:07

If you want to learn the maths and how it is all connected and what equations are better suited to prevent rounding errors and such, have a look at this paper which includes the Exponential Moving Average:

 
Mladen Rakic:

I am afraid I do not know who "Ahl" is ...

In any case you are missing the loop part in what you are trying to compare (in the original method you have to check the next few lines too), this part :

{calculate current gain factor K}
e=1;
Kold=1;
while e>tol begin
        K=v3*Kold*(2-Kold);
        e=Kold-K;
        Kold=K;
end;    

and you can not do that (if you omit that loop part in the original method, then you are missing the whole point)

Anyway : the correction to Uhl's method was made in order to allow that method to :

  • be more CPU efficient
  • be usable on any set of values (without a need to set some minimal gain)
  • since more or less the gain is quite similar in both cases (methods) of calculation - except with the above described reasons for change, I do believe that the method I am using is usable in any set of values (unlike the original method)

Also, I do not understand the point about lagging. The whole point about "correcting" is to filter out the not-necessary noise : ie. to lag (if you want to call it that way)


Sorry the name of a classmate is Dr. Ahl and I mixed it up with Dr. A. Uhl - kind of Freudian slip  :) -  sorry.

About the lag, just look at the 'aqua-lines': Nov. 17 12:00 is a local high and it's the first candle starting the "waterfall" it takes 12 bars (Nov. 17, 21:00) before Uhl starts to fall.

And one could say that the next 'sidewards walk' of the prices starts at Nov. 17, 19:00 and Uhl begins it next 'horizon' at Nov. 18, 09:00 which is 10 bars later.

I know the problem of the relation of filtering at the costs of lag but here in this case Uhl acts after all has already happened and the money could have earned earlier.

At least its a hint that Uhl might be more interesting and helpful for shorter timeframes than h1 - no?

 
Carl Schreiber:

Sorry the name of a classmate is Dr. Ahl and I mixed it up with Dr. A. Uhl - kind of Freudian slip  :) -  sorry.

About the lag, just look at the 'aqua-lines': Nov. 17 12:00 is a local high and it's the first candle starting the "waterfall" it takes 12 bars (Nov. 17, 21:00) before Uhl starts to fall.

And one could say that the next 'sidewards walk' of the prices starts at Nov. 17, 19:00 and Uhl begins it next 'horizon' at Nov. 18, 09:00 which is 10 bars later.

I know the problem of the relation of filtering at the costs of lag but here in this case Uhl acts after all has already happened and the money could have earned earlier.

At least its a hint that Uhl might be more interesting and helpful for shorter timeframes than h1 - no?

I will use my favorite phrase : "As usual some experimenting is advised"

I am not posting "carved in a stone" versions. If you feel it should be used differently on a different than the example time frames (and symbols), then why not? After all the code and parameters are there to allow changes - not to suggest that it must be used as it is coded and displayed in the example (that is more of an illustration than a guide)

All the best

Reason: