|
PureBytes Links
Trading Reference Links
|
P.S
My gut feeling is that you pulled the wrong rein and made a mistake
on some aspects of that one (well actually you did pull the right
rein but now you need to pull it again and a bit harder this time).
As you well know, I can't give you any technical reasons.
To me the AB 'internal' database is the foundation of core
functionality.
I think that is what some of the users are telling us when they say
they like artificial tickers.
If I was in your shoes, and considering that you laid the foundation
years ago, I would have opened the AB database right up with
additional builtin and user defined arrays.
Let us see AB in her full glory the way she is meant to be.
I don't agree that would be cluttering AB up with stuff that would
hardly be used.
Remember, users are becoming much more sophisticated at a rapid pace.
What would have seemed too much information back in 95 is now taken
onboard without a break in stride.
Never underestimate people.
If you put on the show the public will come.
I admire you for openly telling the truth about your program and
also explaining your reasoning as that honesty is an optional extra
and not mandatory; you are one of a rare breed that's for sure.
More power to you Tomasz.
I am also very happy with the universal database plug-in.
As you say it permits 'flexibility allowing individuals to extend
> its functionality. And here you are limited only by your
> > imagination'.
I am also happy that, while we agree to disagree on some issues, I
now know what your guiding philosophy is and I can manage my affairs
around that.
BrianB2.
--- In amibroker@xxxxxxxxxxxxxxx, "brian.z123" <brian.z123@xxx>
wrote:
>
> Thanks Tomasz,
>
> I have been speculating about that stuff for a while now so it is
a
> relief to get presented with the facts and have it all cleared up.
>
> BrianB.
>
> --- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <groups@>
> wrote:
> >
> > Hello,
> >
> > The reason why fundamental data implemented in AB are current
only
> are as follows:
> >
> > a)
> > Yahoo nor any other free source of fundamental data does not
> provide historical values
> > for majority of fields. The idea behind new fundamental data
> functionality in AB
> > was to couple it with a method to actually RETRIEVE this data
> automatically.
> > Since only current values are available from Yahoo, so there was
> no point in bumping
> > database size for functionality that would be left unused for
most
> people
> >
> > b)
> > The idea was to help scanning (stock picks) based on
fundamentals
> only.
> >
> > Backtesting systems based on fundamentals requires 20+ years of
> data to make any sense
> > (because they change so infrequently - otherwise you would have
> too small data sample to make results resonable).
> >
> > Since AB target user base is not really that long-term
investors,
> and there are no
> > free data (see a)) it made even less sense
> >
> > c)
> > The idea was to add functionality without growing database - AB
> database format was prepared
> > for fundamentals since day 1 (May 1995) but there were no method
> to access these fields.
> >
> >
> > As to SQL advantages: using external database
> > a) you have unlimited number of custom fields of any type
> > b) you can store less frequent data effectively (if you have
> quarterly data using external database
> > you would store just 4 records per year)
> > c) you can access these data from external ODBC-aware programs
> >
> > Overall the general idea of AmiBroker is as follows:
> > a) core functionality is provided internally + means to easy
> update from FREE sources
> > b) extra functionality is provided by means of plugins /
external
> sources / scripts
> >
> > This design ensures that
> > a) AmiBroker is not bloated with stuff that almost no one is
using
> > b) AmiBroker delivers flexibility allowing individuals to extend
> its functionality. And here you are limited only by your
> > imagination.
> >
> > Best regards,
> > Tomasz Janeczko
> > amibroker.com
> > ----- Original Message -----
> > From: "treliff" <treliff@>
> > To: <amibroker@xxxxxxxxxxxxxxx>
> > Sent: Sunday, July 23, 2006 9:41 AM
> > Subject: [amibroker] Re: On Fundamental data import
> >
> >
> > > 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, "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.
> > >> >
> > >> > __
> > >>
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > 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
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
|