Geometric and Arithmetic Mean Divergence Oscillator (GAMDO)
Author: Eugene
Creation Date: 9/25/2009 3:12 AM
profile picture

Eugene

#1
David Varadi's latest creature:

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 Community.Indicators:
CODE:
Please log in to see this code.
profile picture

Eugene

#2
Now a part of Community.Indicators too.
profile picture

zorgnak

#3
Thanks Eugene.."Creature" is an apt description.
profile picture

avishn

#4
Not sure this is correct. Shouldn't it be a product or 1+ROC and then (n-th root of it)-1?
CODE:
Please log in to see this code.


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

Eugene

#5
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.
profile picture

avishn

#6
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 --

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.

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).
profile picture

Eugene

#7
This is great, thank you.
profile picture

Eugene

#8
Hmm. When I plug this data series into the formula, I get a blank plot:
CODE:
Please log in to see this code.

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

avishn

#9
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):

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.
profile picture

avishn

#10
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.
profile picture

Eugene

#11
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, PercentRank is being used as a helper for building DV's indicators (afair) vs. standalone indicator. Hence it's not exposed to the Indicators list and not documented in the Wiki.
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.
profile picture

avishn

#12
I don't think Community.Indicators' PercentRank implementation is correct --
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.
profile picture

Eugene

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

avishn

#14
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.

profile picture

DartboardTrader

#15
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.

CODE:
Please log in to see this code.
profile picture

Eugene

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

paul3nt

#17
.
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.



profile picture

Eugene

#18
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.
profile picture

paul3nt

#19

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.
This website uses cookies to improve your experience. We'll assume you're ok with that, but you can opt-out if you wish (Read more).