[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GT] Re: Re: Re: EMA incorrect when using --nb-item
Nick Fantes Huege wrote:
It seems that the root of our misunderstanding was that you read the
pod and I read the Perl code. Since this is the development mailing
list, I just wanted to point out something I thought was a logical
error in the Perl code.
There is already --max-loaded-items, which clearly states (and I have
verified its claims by analyzing the Perl code) that it controls the
number of periods (back from the last period) that are loaded for a
given market from the data base. This option is effective only for
certain data base modules and ignored otherwise.
Why would anyone want to use both --max-loaded-items and --nb-item?
The first one already intelligently limits the data pulled from the
database, and the second one further creates a subset from the already
limited data. This results in displaying wrong data in the example
when calculating EMA.
Just to clarify something:
./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.
Both commands are absolutely equal because --last-record is a
synonymous for --nb-item=1
Best regards,
Nick
nick
i have to agree with you that --nb-item when used with display_indicator.pl
is again (still?) showing discrepant results,
% ../svn_repo/Scripts/display_indicator.pl I:EMA YHOO 200 | tail -1
EMA[200, {I:Prices CLOSE}][2010-07-21] = 15.6130
% ../svn_repo/Scripts/display_indicator.pl --last I:EMA YHOO 200 | tail -1
EMA[200, {I:Prices CLOSE}][2010-07-21] = 16.0171
% ../svn_repo/Scripts/display_indicator.pl --nb-item=1 I:EMA YHOO 200 | tail -1
EMA[200, {I:Prices CLOSE}][2010-07-21] = 16.0171
so i fall back on my previous statement:
historically option --nb-items has had a tortured history of purpose, use and
implementation.
but whether this is a fault of --nb-item=1 --last or I:EMA or something else
is still to be determined ...
assuming it's --nb-item before 'fixing' it is undertaken, maybe a discussion
about what it's purpose is (or should be) would be a better place to start:
i still think it's (and supposed to be) a way to anchor one end of the input
data range without resorting to a date string. this is important and significant
because (at least for me) it is easier to determine i want 120 bars in the chart
ending on 1jul08 than for me to figure out what that starting date would be.
the use of Date::Manip has reduced the need for --nb-items, but it still might
be useful in this manner.
however, i get the sense that based on your reading of the code you believe
it should (maybe it actually does) dictate the amount of data to report. i
maintain that wasn't the intent, but maybe what has actually happened
(i dont think so in most instances, but maybe in one or some) so that's where
we should probably start off the discussion?
i see no point in an option that limits the amount of output data from apps
like display_*.pl when a simple pipeline would perform just as well.
i don't see any point for such an option for scan.pl or any of the backtests.
for graphic.pl it might be useful but i think there are larger issues with
graphic.pl than just limiting the chart size.
i do see a real need for being able to anchor one end of the processing date
range with a simple integer value that represents the number of bars in the
analysis period.
as far as --max-loaded-items this mechanism is outside of the handling of any
associated data dependencies, so if you have a 200 day sma but set
--max-loaded-items to less than the full start-end data range plus 200 days
(might be 201) the first sma values will be wrong.
the need for --max-loaded-items is to limit (within reasonable limits) the
data read from a stocks database that may go as far back as the early 1920s.
this option is not supported, simply ignored with file based data bases.
when correctly implemented using both --max-loaded-items and --nb-items plus
one of --start or --end can effectively limit the amount of unnecessary data
being read from and stored by gt, and set the analysis range using one date
string and a number of bars to consider in the analysis. note that --nb-items
is handled within the context of the specified gt data dependencies, so any
additional data needed to satisfy an indicator that needs 200 days prior to
--start is *supposed* to be available in the 'analysis range'.
also note carefully thomas weigert comments about ema being a indicator that
is hard to start ... we believe the gt implementation is reasonable and technically
correct, except maybe for a corner case or two when dealing with atypical conditions.
aloha
ras