[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GT] ADX
Weigert, Thomas wrote:
Does anybody know a reliable way of checking the behavior of the ADX
indicator?
As implemented it does not match the corresponding indicators in tools I
have access to (Metastock, EclipseTrader, TA_LIB). Note that none of
these agree with each other either.
I reimplemented it based on the description that I found in metastock,
but that does not match the original implementation, nor the other ones
listed above either.
I realize that there might be differences due to whether Wilder's
smoothing is used or EMA or SMA, but the values obtained in the various
implementations are too inconsistent.
I am attaching my new version, if you care....
Th.
thomas
of course we care, but ... there's always a but
humm -- the module name Wilders doesn't give a non-(Metastock, EclipseTrader, TA_LIB)
user much information as to the type (nature) of this indicator
ah -- good explanation in the pod it is a welles wilders smoothing scheme akin to ema?
how about wwma -- oops there already is an wwma. what if anything does wells wilders
call it, or the ta community? maybe something involving 'classic' and 'exponential average'?
tangent on
and gee they (wilder and wwma) don't generate the same results -- but that's not too surprising.
is there a (mathematical) way to determine if one is wrong? or are we subject
to ta-lib says this, Metastock that ...
would 'programmatic' price databases be helpful in assessing an indicators' algebraic results?
example 1: 1.00 close with open at 1.00, hi and low +-0.50 with constant volume.
example 2: 1.00 close with open at 1.00, hi and low +-0.50 with volume that
varies on a sinusoid of amplitude a, freq f, on top of 'dc level'.
example 3: price varying on a sinusoid of amplitude a, freq f, on top of 'dc price level'.
open at prior close, hi and low +-0.50 of todays close.
tangent off
crap -- i'm not too partial to 'dies' in the middle of a program;
this one is of the particularly annoying type. but (there's always a but)
i like the fact that the indicator makes the effort to check it's args and
report problems. however, when triggered, you get a perfectly accurate, but
relatively unhelpful message:
'Argument 1 must be a constant value.'
the following info added to the error message would be a big help:
@ the module (indicator) that is complaining
@ the Argument that is being complained about
in place of:
die "Argument 1 must be a constant value.\n" unless $self->{'args'}->is_constant(1);
this will do that:
unless ( $self->{'args'}->is_constant(1) ) {
print STDERR __PACKAGE__ . ": error: Argument 1 \""
. $self->{'args'}->get_arg_names(1) . "\" must be a constant value.";
die "\n";
}
ras [ 5788 ] % ./display_indicator.pl --start 2008-02-10 --end today \
I:Wilders AAPL '{I:HilbertPeriod}'
GT::Indicators::Wilders: error: Argument 1 "{I:HilbertPeriod}" must be a constant value.
items of note: die (and warn) print to STDERR. at least on solaris sparc 10/perl 562,
STDERR and STDOUT share different buffers, one (STDERR), gets printed first, followed
by the other, on program termination. so the ordering is usually inconsistent when
mixing STDERR and STDOUT, but expecting execution order display.
the work in indicators in the past week or two has been simply phenomenal. i cannot
give thomas and karsten anything but thanks thanks and more thanks.
i'm in the midst of 'other' work right now, but am staying on top of the new packages
(keeping the version changes in local rcs). i intend to test and evaluate them, and
with authors/(modifiers) final approval, commit them, but please bear with me. in the
mean time current users/and list subscribers are encouraged to do their own evaluations
and offer comments via the list.
and if we get very lucky some of the prior gt gurus will even 'weigh in'.
aloha
ras