RE: [GT] New EMA

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

I think most indicators in GT work like this:

1. if you evaluate the indicator via "calculate", they skip until legal
data is encountered, possible generating loads of error message.

2. if you evaluate the indicator via "calculate_interval", they abort if
you request times out of range.

This is due to that the latter use 
  return if ! $self->check_dependencies_interval (...)
which stops all evaluation, while in the former we just return from the
evaluation of a single data point...

So the one's that don't abort are the one's that do not have
calculate_interval defined, but those are much slower, unless there are
not many series involved in computing the indicator.

Th.

> -----Original Message-----
> From: Robert A. Schmied [mailto:ras
AT
acm.org]
> Sent: Thursday, February 28, 2008 11:20 PM
> To: devel
AT
geniustrader.org
> Subject: Re: [GT] New EMA
> 
> Weigert, Thomas wrote:
> > Yes, as usual in GT, when you try to get the value of an indicator
> > before the dependencies are satisfied, it will complain. This
indicator
> > is available only from 1993-1-29 on for EMA(20).
> >
> > I put an additional test in that causes the indicator to abort in
these
> > cases. Thus data will only be returned if the dependencies are
> > satisfied.
> >
> > That raises the interesting question: How should one handle requests
for
> > data where dependencies are not satisfied.
> >
> > In GT in general the series is aborted (if calculate_interval is
used)
> > or the data is skipped until legal data is found (if calculate is
used).
> > Of course, often one could make calculate_interval be more
forgiving, as
> > in this case, but we should decide on a consistent pattern.
> 
> seems to me that skipping until output can be found is the best
approach
> at least for graphic use. on the other hand if the series aborts and
> outputs nothing some sort of indication (possibly multiple) should be
> presented to the user other than just 'nothing'.
> 
> the possibly multiple means set the return code as well as any other
> text message output to one of stdout or stderr. the return code to
> indicate an error return condition, but that is beyond the control
> of indicator class modules i think, besides none of the gt scripts
> do anything like that.
> 
> ras
> 
> >
> > Th.
> >
> >
> >>-----Original Message-----
> >>From: Robert A. Schmied [mailto:ras
AT
acm.org]
> >>Sent: Thursday, February 28, 2008 9:14 PM
> >>To: devel
AT
geniustrader.org
> >>Subject: Re: [GT] New EMA
> >>
> >>when operating at the start of data it complained:
> >>ras [ 5148 ] %    ./display_indicator.pl --start 1993-01-04 --end
> >
> > 1993-07-
> >
> >>01 I:EMA 13000
> >>Indicator I:EMA has 1 value ... all values selected
> >>        I:EMA/1  <=> EMA[20,{I:Prices CLOSE}]
> >>
> >>        timeframe day, time periods 0 .. 123
> >>Calculating indicator ...
> >>Use of uninitialized value in subtraction (-) at
> >
> > ../GT/Indicators/EMA.pm
> >
> >>line 126.
> >>Use of uninitialized value in addition (+) at
../GT/Indicators/EMA.pm
> >
> > line
> >
> >>126.
> >>EMA[20,{I:Prices CLOSE}][1993-01-05 00:00:00] = 1.9978
> >>EMA[20,{I:Prices CLOSE}][1993-01-06 00:00:00] = 3.7676
> >>EMA[20,{I:Prices CLOSE}][1993-01-07 00:00:00] = 5.3456
> >>
> >>so i hacked around and came up with
> >>
> >>    my $ema;
> >>    for (my $i = $first+1; $i <= $last; $i++) {
> >>        my $oldema = $indic->get($name, $i - 1);
> >>        ( defined($oldema) )
> >>          ? $ema = $alpha * ($self->{'args'}->get_arg_values($calc,
> >
> > $i, 2)
> >
> >>- $oldema) + $oldema
> >>          : $ema = $alpha * ($self->{'args'}->get_arg_values($calc,
> >
> > $i,
> >
> >>2));
> >>        $indic->set($name, $i, $ema);
> >>    }
> >>
> >>you may have a better option, but it solves the issue noted above
and
> >
> > i
> >
> >>think
> >>the answers remain the same.
> >
> >
> >