Re: [GT] Trouble with backtest.pl and beancounter

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

Weigert, Thomas wrote:
> The true reason, I believe, is different for this problem...
>
> Somebody wanted to provide support for multiple files for a given
> market, with different timeframes per file. E.g., IBM.day.csv,
> IBM.week.csv, IBM.30min.csv, etc.

don't think this applies when using the bean or pg modules.

i knew there was more reason to dislike genericdbi, than just
requiring users to know how to craft sql queries.

> The data access routines were changed to work as follows:
>
> 1. try to load the market, e.g., IBM.csv, if no data is found,
> 2. try to load the market for IBM.<timeframe>.csv, where <timeframe>
>    Is the current timeframe; if no data is found,
> 3. move to the next shorter timeframe and go to (1).
>
> Note that the file name tried with timeframe can be configured using the
> configuration variable DB::text::file_extension and
> DB::genericdbi::prices_sql::<timeframe>.
>
> However, this scheme works only for data in Text files and genericdbi.
> All other data access mechanisms "die" if data is not loaded correctly
> for the default market.
>
> Note that this scheme is not really the best. Any data access that does
> not support this scheme (e.g., bean, HTTP, pg, Metastock, CSV)
> needlessly has a loop built in trying to load non-existent files until
> it hits the die statement.
>
> These scheme also prevents a sensible error message, as we do not know
> whether the problem is from accessing data not there because of the
> timeframe or because it is not there, period.
>
> I think that lookup for additional data files or data sources should be
> pushed into the data base module, so that we can avoid aborts or give
> better error messages.

i'm not sure what you mean by 'additional data files or data sources'?

from my simplistic view it would seem to me if a prices data access
fails for a given $code one could attempt a name data access for that
$code, if that access also fails it's rather likely that the database
doesn't have support for that $code. (yes, i realize that it might
have to be $code.$timeframe.$fileext)

how to implement this across all supported databases is the challenge.
most of the needed stuff exists (get_db_name) for the dbi apis, but
are issues with the file based ones.

of course my view from bean.pm is different than that from Text.pm
or genericdbi.pm.

changes in this area should
* not invalidate the operability of the legacy db interface schemes
* provide meaningful user error messages
* provide performance improvement

additionally, it would be a good thing if there was a mechanism that
provided a generic database query, unfortunately probably requiring
custom sql. i would find that useful for extending the data displayed
by graphic.pl to include stuff like market cap, shares outstanding,
earnings, dividends. the list goes on and on. but this is way way
way out-of-scope.


aloha


ras


> Th.
>
>
> > -----Original Message-----
> > From: Robert A. Schmied [mailto:ras
AT
acm.org]
> > Sent: Monday, May 05, 2008 12:27 PM
> > To: devel
AT
geniustrader.org
> > Subject: Re: [GT] Trouble with backtest.pl and beancounter
> >
> > Nicholas Kuechler wrote:
> >
> > > Thanks for the reply.
> > >
> > > Regarding: "The beancounter DB module does not support intraday
> >
> > data."
> >
> > > I did some checking to figure out what the problem with my data, so
>
> I
>
> > added
> >
> > > the $code to the message, so I could see what data was in my
>
> database
>
> > for
> >
> > > that code.
> >
> > nick, thomas and all other interested gt'ers
> >
> > i never really understood why that die message was so poorly
>
> configured
>
> > and have removed it from the bean.pg i use (and have added
>
> considerably
>
> > more). in any case, the general recommendation (and i'm not sure that
>
> i
>
> > agree with it, is that all sql based database (maybe that should be
>
> sql
>
> > databases that support the dbi api) users should adopt the
> > genericdbi.pm
> > module.