Re: [GT] New EMA

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

Weigert, Thomas wrote:
> I think most indicators in GT work like this:

maybe most, but not all ... 

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

sma for example has a "calculate_interval", doesn't abort.
zigzag, the prior version of ema ;-), HilbertPeriod, don't abort
(ah just because the method is the doesn't mean it's actually invoked!)

also these all operated very cleanly, without annoying messages. i should
also state that they are in my operating environment, not the repository.

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

i'm thinking we can (re)code them to operate 'appropriately' regardless of prior
practice/art/convention/happenstance.

since i'm primarily a visual kind of user, i'd like to see an ipos' chart
that starts off without my usual sma 20, 50, 200 and have them automagically
appear on the chart at the appointed time period. same goes for bollingerbands,
aroon, and the cmo.

i think the prior version of ema is much faster than the old one. it appears
that macd has had a marked speedup. not easily evaluated, but not impossible either.

i like what is happening

aloha

ras

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