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 [email protected], "Michael.S.G." <[EMAIL PROTECTED]> 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 [email protected] <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. > > > > > > > > __ > > > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Yahoo! Groups gets a make over. See the new email design. http://us.click.yahoo.com/XISQkA/lOaOAA/yQLSAA/GHeqlB/TM --------------------------------------------------------------------~-> Please note that this group is for discussion between users only. To get support from AmiBroker please send an e-mail directly to SUPPORT {at} amibroker.com For other support material please check also: http://www.amibroker.com/support.html Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/amibroker/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
