|
PureBytes Links
Trading Reference Links
|
Hello Michael,
I was a little biased against artificial tickers but I am picking up
the message from longer term users that some like that method.
Maybe it is horses for courses.
I have an open mind now and maybe I will use ODBC/SQL/artificial
tickers for different tasks or later on come to favour one over the
other.
BrianB2.
--- In amibroker@xxxxxxxxxxxxxxx, "Michael.S.G." <OzFalconAB@xxx>
wrote:
>
> Yes this would be true if you imported every day. And as you say,
Fnd
> data just doesn't change enough for daily storage.
> But as fortune may have it, My Fundamental data source is monthly.
So im
> only importing "Changing" data on a monthly
> basis. The easy solution to bloated artificial tickers for Fnd
data
> would be to only import this data monthly. No problems there.
>
>
> treliff wrote:
> >
> > Being a long-time artificial ticker-er myself (and an absolute
non-
> > programmer) I think one disadvantage of this method is that,
assuming
> > a daily data base, we are creating arrays with many, many
duplicate
> > values. For example an array containing EPS (in one of the OHLCVI
> > fields) would only change about 4 times a year; during 3
consecutive
> > months we are stuffing this array with the same value.
> >
> > I can imagine this simply puts a lot of strain on the AB
database.
> > And for example 30 fundamentals divided among 5 arti-tickers for
each
> > stock increases a 2,000 stock database to 10,000 "stocks".
> >
> > I am just assuming this because if not, then why would TJ not
have
> > implemented the new fundamentals as arrays, in this case not
with 6
> > OHLCVI datafields but with one single datafield, so indeed daily
(or
> > bulk ASCII) imported (funda) values would build a historical
database
> > completely within AB similar to price data.
> >
> > I remember though having read requests for "custom arrays" in
deep
> > historical depths of the message board archives, so there must
be a
> > good reason why these were never implemented.
> >
> > But just as dbirru I'd be very interested to know if SQL will
have a
> > serious advantage over artificial tickers. I am absolutely
ignorant
> > about SQL so will this be worth digging into?
> >
> > Thanks very much for advice from TJ or other experts.
> >
> > -treliff
> >
> > --- In amibroker@xxxxxxxxxxxxxxx <mailto:amibroker%
40yahoogroups.com>,
> > "Michael.S.G." <OzFalconAB@>
> > wrote:
> > >
> > > If you import your fundamental data into artificial tickers (eg
> > > Code-FndData) to create a historical database of Fnd Data,
> > > Then it appears as though these new additions have little
benefit
> > to us.
> > > I do the same thing, And reference with Foreign.
> > >
> > > I find it quite convenient to access historical fundamental
data
> > > "within" amibroker, As opposed to accessing some external DB.
> > > I mean, AmiBroker itself is a DB. So why make things more
> > complicated
> > > by accessing external db's. (Just my thoughts).
> > > Im not sure it would be any quicker using external database as
> > opposed
> > > to AB inbuilt Foreign function.
> > >
> > > The only gripe I have, And I dare say it would be the same if
the
> > data
> > > was stored in an external DB - Is the inability of the
> > > shiftx or ref() functions to access Future Foreign data (As in
> > reference
> > > to the Selected ticker).
> > >
> > > Here is example of charting historical fundamental data
accesed via
> > an
> > > artificial (foriegn) ticker.
> > >
> > >
> > > dbirru wrote:
> > > >
> > > > Is the new fundamental import faster compared to doing it
via the
> > old
> > > > way of the ascii importer?
> > > >
> > > > I used to import fundamental data using artifical ticker and
the
> > ascii
> > > > importer (using the 9 or so available fields). In AFL, this
> > requires
> > > > using the foreign function. I find that this method slows
down
> > > > exploration considerably since for every ticker a
corresponding
> > > > ticker need to be read. The values are also stored in an
array.
> > > >
> > > > The latest ascii importer contains additional fields to ease
> > improting
> > > > of fundamental data. Does this new way of improting
fundamental
> > data
> > > > make exploration considerably faster? If the dat astructure
is
> > > > different, then I expect it may be faster. But, I don't know
the
> > data
> > > > structure. Thus, I asked before I try it and 'corrupt' my
> > database if
> > > > it does not offer an advantage.
> > > >
> > > > Thanks.
> > > >
> > > > __
> > >
> >
>
|