[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GT] Re: EMA incorrect when using --nb-item
Nick Fantes Huege wrote:
Hello Ras,
Thank you for your answer! Allow me to respectfully disagree with you
about the use of --nb-items. It seems that its purpose was to limit
the number of results displayed, not computed.
historically option --nb-items has had a tortured history of purpose, use and
implementation. it is believed that the current implementation is consistent
and applied correctly across all apps that use it. but frankly i don't ever
recall the intent for it to throttle the amount of *output* being one of the
(mis)uses.
and yet i have found that when used with graphic.pl --nb-item does give
the appearance that that is what it is doing; but looking deeper it is
really limiting the raw input data. the generated chart data just parrots
the input data range, and a plotted ema is wrong due to lack of sufficient input.
(see more about this towards end where you reference http://stockcharts.com)
the current gt truck for display_indicator.pl (perldoc -t display_indicator.pl)
or on-line pod via http://geniustrader.org/doc/Scripts/display_indicator.pl.html)
says this about the analysis range specifier options:
--full, --start=<date>, --end=<date>, --nb-item=<nr>
Determines the time interval to consider for analysis. In detail:
--start=2001-1-10, --end=2002-11-17
The start and end dates considered for analysis. The date needs to be in the format configured in ~/.gt/options and must match the timeframe selected.
--nb-items=100
The number of periods to use in the analysis. Default is 200.
--full
Consider all available periods.
i submit this is actually how --nb-item is implemented, it is *not* a means
to limit the amount of data being output, but *is* a means to limit the
amount of data being analyzed.
In Scripts/display_indicator.pl we see the following code:
if ($last_record) {
$full = 0;
$start = '';
$end = '';
$nb_item = 1;
}
$last_record is set if we pass the option --last-record.
In other words, if we want to see only the last record (for example
the EMA for today) we add --last-record, which sets $nb_item to 1.
well, i think you are reading this code 'out of context'. if this
is the primary basis for your assertion that --nb-items controls the
amount of displayed items then you need to more fully study how the
actual analysis range is determined.
i stand by my assertion that the pod is correct and --nb-items is
used to limit data quantity in the analysis range being considered.
The above code contradicts with the code in Tools::find_calculator
where $nb_item clearly trumps $full, but yields to $start and $end,
and so participates in the computing of the indicator. To my opinion
this should be fixed, and I don't mind doing it if we agree to it.
If I'd like to see today's EMA(200) for YHOO, I could use this:
./display_indicator.pl --last-record I:EMA YHOO 200
completely equal to:
./display_indicator.pl --nb-item=1 I:EMA YHOO 200
How is a 200 day moving average going to get computed if we only have
one day available?
first off, the command
./display_indicator.pl --nb-item=1 I:EMA YHOO 200
is wrong, because the --nb-item=1 will eliminate most input data,
but the command
./display_indicator.pl --last-record I:EMA YHOO 200
is correct, because it correctly uses the default analysis range,
but only outputs the last record.
that answer should be identical to:
./display_indicator.pl I:EMA YHOO 200 | tail -1
and hopefully to:
./display_indicator.pl --full I:EMA YHOO 200 | tail -1
as well, but if not the variance should be very small.
You ask:
i'm not sure why you would want to use --nb-item=10 and also use a 60
bar time period ema?
The example was supposed to display the last 10 values of a 60 day
oh! i do now see a bad example in the display_indicator.pl pod too
./display_indicator.pl --nb 10 I:EMA IBM 120
if that is the primary cause for your confusion accept that it is
wrong and will be fixed in due course ... suggested examples and
associated explanatory text welcome
EMA, the same way this chart does:
http://stockcharts.com/h-sc/ui?s=YHOO&p=D&yr=0&mn=0&dy=10&id=p58199359097
well, a comparable gt command would be
./graphic.pl \
--nb-items=10 \
--type=candle --volume --title='%n (%c)' \
--add='curve(I:EMA 60, darkblue)' \
--add=Text'("EMA 60",2,95,left,center,small,darkblue,arial)' \
YHOO > graphs/yahoo.nick_nb10.png
but as you correctly note, the plotted ema is invalid, because there's insufficient
data to plot it. in fact i don't think it's possible to plot a chart of this
sort with gt, but if you try:
./graphic.pl \
--type=candle --volume --title='%n (%c)' \
--add='curve(I:EMA 60, darkblue)' \
--add=Text'("EMA 60",2,95,left,center,small,darkblue,arial)' \
YHOO > graphs/yahoo.nick.png
or
./graphic.pl \
--nb-item=120 \
--type=candle --volume --title='%n (%c)' \
--add='curve(I:EMA 60, darkblue)' \
--add=Text'("EMA 60",2,95,left,center,small,darkblue,arial)' \
YHOO > graphs/yahoo.nick.png
the ema is well formed and consistent with the stockcharts.com example
for the few bars being plotted ...
I still think that &calculate_interval in EMA.pm must be fixed to set
--full=1 (or $first = 0) in order to present as accurate moving
average value as possible. Otherwise any signals that use --nb-item
are going to be misleading.
ah humm ''signals that use --nb-item''. i'm not sure i fully understanding
what you mean by this. the display_*.pl scripts aren't really there for
'trading or stock analysis purposes' but are tools for developing and trouble
shooting the various sys-sig-indic descriptions used in scan.pl, the backtests
and or graphic.pl. sys-sig-indic description are used by gt to 'program'
how trading system analyses process data objects (see below) to do their
thing.
i may be preaching to the choir here, but gt is heavily object-oriented;
as such, the methods in Indicators as well as those in Signals and Systems
presume a correct input data object to operate on. if the input data object
is wrong then corrections should be made to the method(s) that are creating
the data object not in the methods that are using it. so, in this instance,
if there is a problem with the data object that is being created by the
command
./display_indicator.pl --nb 10 I:EMA IBM 120
then the fault is in Tools::find_calculator and or associated methods and
subroutines including possibly the application script or it's usage. in this
case i submit the command is in error because the purpose of --nb is misunderstood
by the user.
to limit the number of data lines use
./display_indicator.pl I:EMA IBM 120 | tail -10
aloha
ras
Regards,
Nick