|
PureBytes Links
Trading Reference Links
|
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@xxx>
> 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.
> > >
> > > __
> >
>
|