|
PureBytes Links
Trading Reference Links
|
....and to think I could have inadvertently or by error missed your seminar
post.
-----Original Message-----
From: amibroker@xxxxxxxxxxxxxxx [mailto:amibroker@xxxxxxxxxxxxxxx]On
Behalf Of brian.z123
Sent: Tuesday, August 15, 2006 7:56 PM
To: amibroker@xxxxxxxxxxxxxxx
Subject: [amibroker] Re: Unweighted Composites (again!)
Tim,
As in most trading discussions it is `horses for courses'.
It is often difficult to arrive at absolute or error free outcomes,
as the Decision Point (DP) article states:
`The bottom line is that different methods of calculating market
indexes will render different results, so it is important to
understand how an index is derived and what it intends to
convey??????
Since we didn't account for index component changes during that
prior two years, the indexes for that period are not 100% accurate."
I also find value in thinking outside the box e.g. I might have a
more expansive definition of `indexes' than the mainstream.
In this topic we are talking about at least three different indexes:
1. a cumulative total of the average %gain of each stock member
per period,
2. a cumulative total of the %gain of each stock member per
period,
3. a cumulative total of the %gain of `equal portfolios' per
period.
There is also a consideration of zero-based versus `number based'
indexes, weighted versus non-weighted, and cumulative versus ATC.
I can't see any difference between the last two terms as far as the
outcome goes.
Point 2 and point 3 are lifted straight from the DP article:
"Calculate the daily average percentage change of each stock in the
index, and increase or decrease the prior day's index value by that
percentage?????????????????
We have to assume that the theoretical dollar value of the index is
equally distributed among each issue in the index at the beginning
of each market day."
I have posted a file at this AmiBroker Group file site under
Indexes/Composite.xls to illustrate some of the arguments from my
first post (I might take the folder and file down after a while).
The file tracks the three indexes we are interested in for 3 Bars or
2 Periods.
In places I interchange %, say 0.63%, with %factor 1.0063 for
calculations.
Index 1 (highlighted in green ? table 1).
Table one, period 1, illustrates that for three stocks of different
prices the average ROC% change of the stocks can be positive (cell
C8) while the ROC% for the `portfolio' is negative (cell F12) and
the portfolio lost money.
This is because method 1 is still weighted by the larger priced
stocks.
As stock C, the highest priced stock, fell ? 1.7%, it influenced
the `index' disproportionately.
So for average ROC% indexes there is no obvious relationship between
the index and the change in the portfolio.
Index 2 (highlighted in grey ? table 1) leads to similar conclusions.
Index 3 (refer to table 2).
Table 2 contains exactly the same data and calculations as table 1
with the exception that the stocks in the portfolio have had `money
management' rules applied.
We have now purchased equal $values of each stock i.e. 10 shares of
stock A, 2 shares of stock B and 1 share of stock C.
We can see that for `equal $ weighted' portfolios the ave %ROC index
tracks the portfolio for the first period.
To maintain the equal weighted nature of the index it might be
necessary to rebalance the portfolio every period.
I would say that this is what the article is referring to.
This might involve some tricky code; I'm not sure having gone no
further at this point.
I started to suggest in my previous post that as Ami provides foreign
("~~~ equity", "X"), it might be more fruitful to use that for the
task as it has portfolio equalization built-in.
The trick there might be to compare/overlay Ami portfolio equity for
your database/watchlist against the industry index of your choice or
any other composite.
Possibly an Ami composite of, say the XYZ100 components, could be
calculated using the same formula as your database/watchlist of
interest for comparison purposes.
There might be ways to use AA to give you an equal $weighted buy and
hold index e.g. add the component members of the XYZ100 to your
portfolio, assign each a 1% equal weighted $ value using money
management rules in AA, use buy C on date of your period as the
entry and sell C on the last date of your period as the exit, run a
back-test and plot the resultant ~~~equity curve (the default equity
histogram can be changed to line view).
Obviously, if your interest is in comparing database subsets
(watchlists) or rotating subsets (watchlists) it gets quite a bit
trickier, as the previous composite topics discussed in the forum
show.
In my first post I also introduced the possibility of using a
fourth `index'.
In the spreadsheet tables it is highlighted in yellow.
It is a smoothed curve that I would describe as the exponential mean
of the portfolio, although that might not be the correct
terminology, as I am not mathematically trained.
It is calculated by multiplying the starting portfolio by the
average portfolio ROC% for any period(s).
It can be derived from starting and ending portfolio values (refer
to table 2 ? cell K13, K15 -highlighted in blue).
Possibly this `index' offers a quick comparison of the relative
value between buy & hold one basket of shares c.f. another but I
haven't followed through on that either.
Most of the examples I have used zero based which offers the
advantage of easy comparison by chart overlay.
Users can add any common number as an initial starting point, which
will simply move the starting point of all indexes up the chart a
bit.
The main thing is that apples are compared to apples and that the
index is actually telling you what you want it to, or as near to it
as one can get.
Mark H; thanks for your code.
It looks like it creates index 1 to me.
It can run in a pane by itself can't it?
BrianB2.
--- In amibroker@xxxxxxxxxxxxxxx, "brian.z123" <brian.z123@xxx>
wrote:
>
> Hello (Tim?).
>
> Would these speculative ideas help?
>
> 1. For a database subset (watchlist etc) that is constant for the
> period:
>
> create a composite (as per Graham's or other code in recent
> composite posts except without the averaging component);
> and then divide ROC(~composite,periods) by periods to standardise
> the composite to % per bar (day, week?).
> That would give you a standardised composite 'momentum' type
> indicator for your watchlist etc.
> I don't know if I would describe it as 'unweighted' as it is
> monentum biased but it might be 'unweighted' by your definition.
> If you want to do it for a complete database you can create the
> composite without looping etc and use ROC/periods in the same way.
>
> 2. For a rotating subset, say a watchlist, create a composite for
> the 'current' bar (day, week, month etc), (without the averaging
> component);
> perform an ROC(~periodcomposite,1) = PC,
> and then create your running watchlist composite of the period
> result ATC(PC etc) over the bar range that interests you.
> There is no need to give any consideration to averaging as the
> ~watchlist has already been standardised to % per period basis.
> The ROC% composite index is also zerobased for any range so there
is
> no need to set and maintain an intitial stating or 'base'value.
>
> If the criteria for rotating symbols in and out of the watchlist
is
> constant over time then method 2 would be going awfully close to
> being a pseudo backtester with the 'composite' plot analagous to
an
> equity curve, wouldn't it?
> An interesting conceptual extrapolation of that idea would be to
> replace the 'watchlist' with a set of trading rules which would
> create a dynamic composite 'on the fly'.
> (I think that idea or somethng like it has been talked about
> somewhere else in AB; maybe by Tomasz?)
>
> As I can barely write a line of code to save myself I can't help
> with specific code or any further clarification.
> I have just offered my comments as a starting point for one
possible
> solution or maybe as an interesting discussion piece.
>
> BrianB2.
>
>
>
> --- In amibroker@xxxxxxxxxxxxxxx, "timgadd" <timgadd@> wrote:
> >
> > After spending MUCH time searching, I have found this topic
> started
> > many times in the group archive, but i've never seen a final
> solution
> > given in AFL. I would greatly appreciate assistance with the AFL
> code
> > or reference to a prior solution.
> >
> > The standard AddToComposite function produces a "price weighted"
> > composite. For analyzing the breadth of a sector, for
> > instance, "unweighted" composites are more appropriate and
> revealing.
> > I have seen the term "equal weighted" used for what i am calling
> > an "unweighted" composite, so i will explain in boring detail
what
> i
> > am looking for just to be clear.
> >
> > By unweighted composite, i refer to one that is produced by
> > calculating an arithmetic or geometric average of the day to day
%
> > change for each component, so that each component has equal
weight
> > (no weighting is introduced by the calculation). I am interested
> in
> > the arithmetic average - the simplest form, but i don't know how
> to
> > initialize the starting value and then cumulate(?) the
successive %
> > change averages for the open, high, low, close (volumes are
simply
> > added). I have seen references regarding problems with averaging
> > values for high and low for this type of composite, so if
> necessary,
> > a composite calculated on the close only will suffice. I am only
> > interested in the average changes between end-of-day values, but
> > would like to produce candlesticks of the composites if possible.
> >
> > Assuming closing values only, each composite will start with an
> > initial value (like 100) and then, for each day, the average of
> all
> > the %changes (from the previous day) will be added to the
> preceding
> > value. Using a simple 3 component composite as an example,
assume
> for
> > the second value of the composite (remember the first value will
> be
> > 100), we have the following %changes.
> >
> > Component1 = +1.2%
> > Component2 = +2.4%
> > Component3 = -1.7%
> >
> > So the first day's average %change = ( 0.012 + 0.024 - 0.017 ) /
3
> >
> > 100 + ((0.012 + 0.024 - 0.017) / 3) + (the next day's average %
> > change) + ...
> >
> > The component values for volume are just added (or averaged) to
> get
> > the daily values.
> >
> > TIA for any help.
> >
>
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
|