TA_MACD calculation
Brought to you by:
fortier
Menu
▾
▴
#55 TA_MACD calculation
The C/C++ API documentation suggests that one can
calculate a function for all bars at once, or you can
get the result for a limited slice of bars from a to b
instead by eg
TA_MACD(a, b,
data,
12, 26, 9,
&outBegin, &outElements,
outMACD, outMACDSignal,
outMACDHistogram)
If outElements == (b-a+1) then the result for bar b
should be
available at outMACDHistogram[outElements-1] (etc).
However, the result obtained in this way disagrees with
the results
obtained by
TA_MACD(0, len-1, // ie all data: I use around 1300 bars
...etc...)
Doing the calculation with a spreadsheet rather than
with TA-Lib produces values that agree exactly with the
results of this latter approach.
The first approach produces results that vary according
to the value of (b-a). The documentation suggests that
it is OK to have a==b, but in this case the results
bear no relation at all to the correct value, and
graphing the output of the first approach when a==b
(ie, doing one TA_MACD call per bar) also shows that
the signal line is not a smoothed version of the
EMA(12)-EMA(26) line - for example, with Vodaphone data
back to 2000, the maximum value of the so-called signal
line is significantly higher than the maximum of
EMA(12)-EMA(26). Ouch!
The larger you make (b-a), the closer the results
become to the true story; but to get a reasonable, 3dp,
approximation it is necessary to make (b-a) be of the
order of 200.
The attached C program lets you play with this: tweak
the value of len2 to see what happens.
program to let you explore TA_MACD results
Logged In: YES
user_id=1123
Just to make things clear, we are not talking about a bug
here, but just observation of the behavior from TA functions
with "memory".
I call the inconsistency that you have observed the
"unstable period".
I provide some info here:
http://www.ta-lib.org/d_api/ta_setunstableperiod.html
You can force the minimum of "200" that you are referring to
using the TA_SetUnstablePeriod().
You can always calculate over the whole data to have the
most "stable" data possible. This is what 99.9% of the other
TA software does, though they rarely filter out the first
few values of MACD that are ALWAYS unstable. This is wrong,
but it seems most of their users are not aware of this
and/or do not care.
Just for the fun, you might want to experiment with
TA_MACDEXT function that allows to replace the EMA with
SMA... you can then see the difference because SMA use a
finite and fix number of past data in its calculation (it
has no memory like EMA). You will then have no such unstability.
Through TA-Abstract, there is a flag that allows your
software to know which functions have an unstable period.
Check all this, and tell me if you are fine with what TA-Lib
does.
\Mario
Logged In: YES
user_id=1315716
Thanks. I'm happy with the behaviour, you can squelch this
"bug". I had read the page about the unstable period but had got
the idea that it merely prevented you from getting results during
the earliest period when transients were significant.
But, I would suggest that you set the unstable period to be
something like 100 by default, because otherwise the series
returned by a sequence of calls each with startIdx == endIdx
does not even have the properties of a smoothed sequence.
It seems like a mistake to have a default behaviour, for the
startIdx==endIdx case as suggested in the API document, that
generates effectively meaningless results.
Peter
Logged In: YES
user_id=1123
Hi Peter,
I will say something paradoxal: I agree with you, but I
prefer not do it...
You surely have done your homework and have a clear
understanding of what this is about, but I can't say the
same for many others. If I set the default unstable period
to 100, many will walk away beleiving that TA-Lib is not right.
3 reasons why I say that:
(1) I have receive often questions like "how come an EMA(15)
have no values for the first 14 input?". Imagine now the
amount of doubt and questioning with an additional gap of 100...
(2) I had an e-mail exchange with a guy where I did explain
the unstable period. He did reply that this was not a real
problem because "MetaStock is not doing anything like this".
He was just not ready to think carefuly about this, but he
might get there one day... My point is: even a noble attempt
to educate people (by forcing on them the unstable period)
might push them away if not ready for it.
(3) If a new user do a quick test using a small array of
<100 for the input, they will think it does not work because
there is no value returned. Not many will persist, read the
doc or ask about it because it is a trivial test that
"should" work. They will move to an alternative instead.
Even if technically not perfect, it works like the other
softwares. The newbie will stick around and hopefully he
will become a serious user and find its way to the
TA_SetUnstablePeriod().
In one sentence: I prefer to open a path to the "right way
of doing" instead of forcing upfront what looks like an
obstacle.
\Mario