RE: [GT] thoughts for cookbook ...

["Weigert, Thomas" <weigert AT mst.edu>]

ras,

thanks for the input. Some quick comments below... Th.

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

> 
> 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. :-(

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

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

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

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