[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GT] thoughts for cookbook ...
Weigert, Thomas wrote:
ras,
thanks for the input. Some quick comments below... Th.
quick back at ya!
aloha
ras
-----Original Message-----
From: Robert A. Schmied [mailto:ras
AT
acm.org]
Sent: Thursday, March 13, 2008 11:19 PM
To: devel
AT
geniustrader.org
Subject: [GT] thoughts for cookbook ...
i)
while it might be over-the-top and out-of-scope, it would be nice to
have an explanation/discussion of when (what other method) calls
each of the indicator methods.
You do not need to know this when you write an indicator. All you need
to understand are initialize and calculate (and calculate_interval, if
you want to speed the indicator up). Maybe I need to make that clearer.
i agree, but before i embark on a hack i tend to want an overall picture
of how the thing being hacked operates, but that's just me.
and gt is one complex app to wade through trying to figure out what package
contains what method ...
like i wrote -- maybe out-of-scope
this might be especially useful for calculate, calculate_all
and calculate_interval which are still something of a mystery to me.
I guess the cookbook has failed. It was meant to explain writing these
three methods. :-(
or maybe it is just this reader that has the failing ;-)
ii) GT::Indicators::calculate_interval($indicator, $calc, $first,
$last);
where the latter would be the inherited method if the indicator itself
elected not to provide its own calculate_interval.)
Yes, but the latter just falls back onto calculate.
yes. i meant to mention that but lost the thread ... that's why
i think (thought) calculate is the only required method. as
inheritance will provide all the others.
calculate_interval (inherited or not) must call calculate as required
to perform the computations.
No. Typically, calculate_interval would not call calculate. However,
there are some other methods that do call calculate, so calculate is
required.
this point needs emphasis, especially because the default (calculate_interval)
just calls prepare_interval (if necessary) and then calls calculate
for time period from first to last
ii) -- covered a bit in 3. output value
at the very minimum an indicator requires a calculate method.
the calculate method must perform all the operations necessary to
compute
the value of the indicator for each time period and then call the
following method with that value, the time period and the indicator
name:
$calc->indicators->set(<indicator_name>, <time_period>,
<indicator_value>);
Correct.
iii) section 4. initialization
when writing an indicator if there are 'expectations' about the nature
of an argument (there are only two kinds of arguments?
constants and functions (series)?
Correct.
so, if for example, an indicator that expects ('requires') a constant
but gets a function (series) should detect it and throw an exception.
same goes for expecting a function (series) but getting a constant.
similarly, if there are no default arguments defined via the
@DEFAULT_ARGS
array and arguments are required an exception should be thrown.
That (and the subsequent suggestions about error handling) would be
wise, but is currently not done.
and that is why it needs to be recommended/encouraged for future indicators
and as an improvement for the current ones.
here's a perl fragment for use in an indicators initialize method
that could serve as starting point to validate indicator arguments.
What I was thinking was to introduce another clause, like
@ARGS = ("C", "C", "S");
with the meaning that the first two arguments are constants, and the
third argument is a series. The error checking could then be called
automatically (well, almost, one would still have to call something like
$self->check_args).
how would error messages be dealt with? i like the concept, but it seems
to add a layer of complexity.
in any case, strategic error detection and exception handling would go a
long way in making gt a bit more user friendly.
see, we are on the same page, just different books ;-)