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 [EMAIL PROTECTED]ps.com,
"brian.z123" <brian.z123@...>
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 [EMAIL PROTECTED]ps.com,
"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.
>
>
>
