Re: [GT] ADX

["Robert A. Schmied" <ras AT acm.org>]

Weigert, Thomas wrote:
> Please see below....
>
>
> > -----Original Message-----
> > From: Robert A. Schmied [mailto:ras
AT
acm.org]
> > Sent: Monday, March 03, 2008 6:08 PM
> > To: devel
AT
geniustrader.org
> > Subject: Re: [GT] ADX
> >
> > tangent on
> > and gee they (wilder and wwma) don't generate the same results -- but
> > that's not too surprising.
>
>
> The difference is that WWMA starts with 0 but Wilders starts with the
> n-day SMA (as stated in Wilders article).

the pod describing the WWMA indicator (which came before your Wilders),
including the calculation equation is identical. if both indicators implement
that calculation using the same input and arguments but get different results
one of the two is either not correctly implemented, or not implemented in
accordance with the pod.

should the Wilders pod state "the initial value will be the n-period sma,
in accordance with < cite Wilders article >" in the calculation section?

assuming WWMA is retained (since it might be used by some other indicator
-- easy enough to check) should it's pod state "WWMA starts with the value
of 0."?

> > is there a (mathematical) way to determine if one is wrong? or are we
> > subject
> > to ta-lib says this, Metastock that ...
>
>
> Most of the time, the papers or articles these indicators are based on
> are not very clear on details, e.g., what starting value to use, what
> smoothing functions to use, etc. So implementers often have to make
> these decisions based on their intuitions. Also, there really is no
> right or wrong here... there is no mathematical reason why one should
> use EMA vs. SMA vs. any of the many other smoothing operations.
yea -- i've been noticing that plus the fact that none of them discuss
how to validate, or otherwise test the algorithms they show are correct,
do what they suggest they do ...

what i was really asking is:
is there a way to validate the programming that implements an indicator
is correct, beyond trying to compare the answers to some other ta program,
or maybe even worse, comparing it's answers to it's own answers, maybe from
a previous, but still otherwise incorrect, version.

(sort of along your line of inquiry reqarding
"a ... way of checking the behavior of ... indicator?")

your response snipped out my query about a programmatic set of price data.
does that strike you as practical? it might allow us to mentally validate
smoothing indicators, and possibly even some of the more complex indicators.

impulse and other step functions, in a prices database, might be useful in
validating indicators using some of the rocket science methods and other
methods operating in the frequency domain.



> > 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
>
>
> That is a good suggestions. I am planning to add a generic function to
> indicators that would allow some error checking to be done
> automatically.

excellent -- code once used multiple

> Th.