Do you want to get informed about new posts via Email?

Geometric and Arithmetic Mean Divergence Oscillator (GAMDO)

Author: Eugene

Creation Date: 9/25/2009 3:12 AM

David Varadi's latest creature:

Geometric and Arithmetic Mean Divergence Oscillator (GAMDO)

Requires**Community.Indicators**:

Geometric and Arithmetic Mean Divergence Oscillator (GAMDO)

QUOTE:

The creation of the oscillator involves taking the arithmetic average of the percentage returns (or 1-day ROCs) over the last 5 days. A geometric average is created by simply adding 1 to the percentage returns and taking the product of this series over the last 5 days (the cumulative return). The geometric average is derived by subtracting 1 from the cumulative return. Then we subtract the arithmetic return from the geometric return to find the divergence. This divergence is smoothed twice using a 3-day average to create smooth signals*(note that the raw divergence produces signals in the same direction). Finally this smoothed divergence is “bounded,” by taking the PERCENTRANK of the series going back 1-year.

Requires

CODE:

Please log in to see this code.

Not sure this is correct. Shouldn't it be a product or 1+ROC and then (*n-*th root of it)-1?

...and related question -- is there a geometric mean indicator available?

CODE:

Please log in to see this code.

...and related question -- is there a geometric mean indicator available?

QUOTE:

Not sure this is correct.

Good catch, thank you. The formula is incorrect. As far as I understand, this is how it should be:

CODE:

Please log in to see this code.

Basically it works, producing Double.NaN here and there. We can work around it like does code below, but obviously something isn't quite right wrt those NaNs but I don't see what exactly:

CODE:

Please log in to see this code.

QUOTE:

...and related question -- is there a geometric mean indicator available?

Probably no or I'd have used it.

It is not clear from Varadi's blog if he's describing standard geometric mean formula or some variation of it. This is the standard --

This is me converting it into a WL indicator --

Please add to Community.Indicators if you think it's of any value.

This is an illustration (not much difference with SMA on price series, I probably should've used a series of daily returns for demonstartion purposes) --

For the purposes of GAMDO I think you'd need to do this:

EDIT: Changed some logic in the main loop of GMA indicator (zero values were screwing the old version up).

CODE:

Please log in to see this code.

This is me converting it into a WL indicator --

CODE:

Please log in to see this code.

Please add to Community.Indicators if you think it's of any value.

This is an illustration (not much difference with SMA on price series, I probably should've used a series of daily returns for demonstartion purposes) --

For the purposes of GAMDO I think you'd need to do this:

CODE:

Please log in to see this code.

EDIT: Changed some logic in the main loop of GMA indicator (zero values were screwing the old version up).

Hmm. When I plug this data series into the formula, I get a blank plot:

This is so because there are NaNs all around. Do you see what I see?

CODE:

Please log in to see this code.

This is so because there are NaNs all around. Do you see what I see?

It turns out ROC returns % change, not a fractional value, so we need to use value of 100 as the basis for daily returns, not 1. The following works for me (cannot tell if the indicator plot is correct or not, but it doesn't fail):

EDIT: Alternative implementation, which more clearly reveals internal mechanics of the divergent series --

EDIT2: There's also this comment https://cssanalytics.wordpress.com/2009/09/26/note-geometric-vs-arithmetic-mean/, which indicates that he is not using standard geometric mean in GAMDO, but rather a "cumulative return" (a product of daily returns). I guess it also means that GMA=Math.Pow(CumulativeReturn, period). In the absence of "reference implementation" of this indicator it would be pretty difficult to make sure that WL's version is correct.

CODE:

Please log in to see this code.

EDIT: Alternative implementation, which more clearly reveals internal mechanics of the divergent series --

CODE:

Please log in to see this code.

EDIT2: There's also this comment https://cssanalytics.wordpress.com/2009/09/26/note-geometric-vs-arithmetic-mean/, which indicates that he is not using standard geometric mean in GAMDO, but rather a "cumulative return" (a product of daily returns). I guess it also means that GMA=Math.Pow(CumulativeReturn, period). In the absence of "reference implementation" of this indicator it would be pretty difficult to make sure that WL's version is correct.

On a semi-related subject -- it seems that PercentRank indicator's Helper class is missing from Oscillators.cs so it is not visible in the right-click indicator list under Community.Indicators.

QUOTE:

On a semi-related subject -- it seems that PercentRank indicator's Helper class is missing from Oscillators.cs so it is not visible in the right-click indicator list under Community.Indicators.

That's right,

QUOTE:

EDIT2: There's also this comment

Good point. Though let's stick with your alternative approach (thank you for sharing) for some time to come.

I don't think Community.Indicators' PercentRank implementation is correct --

Varadi refers to Excel PERCENTRANK function in his post on DV2_Bounded, which is supposed to sort all elements and then assign rank for the given value by determining it's relative position in the sorted list. This is the description --

http://office.microsoft.com/en-us/excel/HP052092121033.aspx

The problem with Community.Indicators' version becomes apparent when applying it to any stock's Close series, for example. It almost never hits exactly 0 or 100 and sometimes values are outside of the 0-100 range.

CODE:

Please log in to see this code.

Varadi refers to Excel PERCENTRANK function in his post on DV2_Bounded, which is supposed to sort all elements and then assign rank for the given value by determining it's relative position in the sorted list. This is the description --

http://office.microsoft.com/en-us/excel/HP052092121033.aspx

The problem with Community.Indicators' version becomes apparent when applying it to any stock's Close series, for example. It almost never hits exactly 0 or 100 and sometimes values are outside of the 0-100 range.

Please look up past discussions on PercentRank, it seems that everyone has his own opinion. AFAIR, there's DartBoardTrader's version inside.

Hmm. It looks like the 0-100 range problem has been subsequently fixed, though the latest version still does not match what Varadi used for his original implementations of GAMBO and DV2_Bounded. I'm not sure I understand why Cone's version (actual translation of Excel's logic, available in one of those discussions) wasn't used for Comm.Indicators instead. Anyways, I think DV2_Bounded and GAMBO probably need to include a disclaimer of sorts that they don't match the description from their author's blog.

This implementation is verified against Excel's output from PercentRank.

Eugene, please rename or remove the previous CommunityIndicators.PercentRank. It was close, but this one is correct.

Eugene, please rename or remove the previous CommunityIndicators.PercentRank. It was close, but this one is correct.

CODE:

Please log in to see this code.

Thank you Michael. For the upcoming release (say September). I'm replacing the old PercentRank with this code.

.

This code cannot be correct. The geometric average is**not** a series.sum of (1+avg(roc)). Is there something like series.multiply ?

If so replace series.sum with series.multiply, and you have got it correct.

However I don't see what possible good a divergence between the geometric average and simple average would be. In general ( unless all of the bar returns are > 0) the geo average for a period > 2 will be less than the simple avg, assuming a log-normal dist. of prices.

This code cannot be correct. The geometric average is

If so replace series.sum with series.multiply, and you have got it correct.

However I don't see what possible good a divergence between the geometric average and simple average would be. In general ( unless all of the bar returns are > 0) the geo average for a period > 2 will be less than the simple avg, assuming a log-normal dist. of prices.

Which "this code" do you mean, b/c there are lots of code? If it's the 1st post, then avishn's reply # 5/14/2010 8:12 AM corrects summing with multiplying.

A rolling or moving Geometric Average of length len is inherently unstable if len < ~ 20. { Try it on Excel and see !]. Here I am using the definition of GeoAvg(Close,len) = ((1+roc(Close,1)[t])*(1+roc(Close,1)[t-1]) * (1+roc(Close,1)[t-2])* . . . *(1+roc(Close,1)[t-Len+1]) - 1) ^ (252/Len).

The idea of a divergence of the rolling or moving Avg(roc(Close,1),Len) and GeoAvg(Close,1),Len) is highly unstable for Len < ~ 20 too. For Len's > ~ 20 the divergence in my view only has a use as a random number generator.