when you say "10 bars ahead"  do you mean prediction?  The historical patterns that we can lift of the charts are inadequate.  What you may explore are genetic or neuro algorithms.  But here also, the predictability, if found, may last only a short time.  You are falling into induction trap (roughly: if in the past A led to B than in the future A1 will lead to B1).  This is a dangerous conviction !  I wrote here once that the fact that I wake up every day and I verify that each day of my life I am alive does NOT mean that I am immortal (sometimes I regret that, but most often I do not). 

My advise: stay in the present.  Choose your favorite set of indicators, calibrate the sensitivity and specificity to the levels that you can live with, add some good management rules ( how much to put on the block, what leverage if any, how much loss can be tolerated, etc.).  Several times you will be wrong and the management rules will bail you out.  A few times you will be right and happy (maybe).  

Roman

--- On Wed, 7/15/09, quickmail1 <quickmail1@...> wrote:

From: quickmail1 <quickmail1@...>
Subject: [LinnSoft] Re: RTL 101 Continued...Divergence
To: LinnSoft@yahoogroups.com
Date: Wednesday, July 15, 2009, 11:34 AM

This is a sidebar food-for-thought post on this subject in general for anyone interested in it. I spent some time on this yesterday, manually creating these tokens and had some thoughts.

ACCEL, or acceleration in general, is 'Rate of Change' of 'Rate of Change'. When an accel token is used, its in a sense predictive of what the next data point might be of an ROC (or other) indicator. (correct?)

But having an indication that a ROC indicator might, for example, be leveling off and maybe be reversing soon, based on consideration of this acceleration, can offer 3 potential assumptions to a respectively stock price that its calculated off of:

1) the stock price is not going to go up as quickly
2) the stock price is not going to go anywhere
3) the stock price is going to go down.

All 3 of these scenarios can reduce a Rate of Change value.

For reference of what ROC is, ROC is for example, (MA-MA.10) or (MA/MA.10). Both the MA and MA.10 are going to continue moving to whatever degree whether the stock moves or not, since both are dependent on historical price movement that will progressively change as well as averaging used in both MA's.

So in itself, the 'ROC of an ROC' isn't a dependable predictor in itself of where the next price of a stock is going to be.

With that in mind, the food for thought is towards how to build on it. What factors of evaluation are needed to predict where the ROC value might be in, for example, 10 bars ahead instead of just one or so (that is, based on the same stock's historical price data, ie not adding Volume analysis etc.)

Beyond that perhaps what it's acceleration rate might be 10 bars ahead too...or simply if it would be positive or negative. Naturally the further out you go out from realtime, the level of reliability or confidence drops.

So would going in this direction be possible/worthwhile /effective, and could it overall serve as a better aid in predicting a stock's (or other instrument or underlying) future price or direction?

John

--- In LinnSoft@yahoogroup s.com, "Chad Payne" <cpayne@...> wrote:
>
> There are two ways to approach this.
>
> Consider the case of:
>
> SLOPE(ROC, 10)
>
> We could just consider a trendline that goes from the start value of ROC.10
> to the current value of ROC. The slope is generally defined as "change per
> bar" (rise over run) and would be:
>
> (ROC - ROC.10) / 10
>
> That would be the simplest and mose efficient method. Then, the
> "acceleration" would just be the change of the slope from one bar to next,
> which would be:
>
> (ROC - ROC.10) / 10 - (ROC.1 - ROC.11) / 10
>
> Alternative, but less efficent, would be to compute a best fit / regression
> line through all the ROC values over the last 10 bar, and then compute the
> slope of that line. Then compute a similar slope for the previous bar, and
> compute the acceleration as the difference between current bar and previous
> bars value. This method concerns me a little because it will introduce a
> much more complex computation, but if that method is much more attractive,
> then it can be done that way.
>
> _____
>
> From: LinnSoft@yahoogroup s.com [mailto:LinnSoft@yahoogroup s.com] On Behalf
> Of quickmail1
> Sent: Monday, July 13, 2009 1:49 PM
> To: LinnSoft@yahoogroup s.com
> Subject: [LinnSoft] Re: RTL 101 Continued... Divergence
>
>
>
>
>
> Absolutely Chad, that would be fantastic. That allows for a static or
> dynamic period of time to be used, and given how involved manually
> creating a CI for slope would be, would be really nice to have as a
> token.
>
> What would a Slope indicator look like? To be honest, the math
> expression might be beyond my math abilities, but for the sake of
> discussion, here are a few thoughts off the top of my head.
>
> If, for example, Slope is using 200 bars (per SSTAT's result), would all
> 200 data points necessarily be analyzed, or could a preference dictate
> how many/how frequent data points are analyzed. And if that is the case,
> could there be an averaging preference to somehow determine whether or
> not/how to average or weight the extraneous data points with their
> nearby data points that are being used, to then use the averaged data
> point results for the Slope calculation.
>
> And if there are prefs for these tokens, could multiple tokens with
> differing prefs simultaneously be used in the same RTL equation, like
> MPD, MPDA, MPDB etc. for using multiple MPD definitions.
>
> It would also be helpful if ACCEL(token, period), "period" could be a
> V#, as well as perhaps an equation. Given the ability you described to
> use SSTAT as the 'period', it sounds like this is what you might have
> had in mind already.
>
> John
>
> --- In LinnSoft@yahoogroup <mailto:LinnSoft% 40yahoogroups. com> s.com, "Chad
> Payne" <cpayne@> wrote:
> >
> > So what you're after is essentially a function for:
> >
> > ACCEL(token, period)
> >
> > which measure the Acceleration of the token over the period. So in
> your
> > example:
> >
> > ACCEL(ROC, SSTAT)
> >
> > let's assume SSTAT is 10 (signal occurred 10 bars ago), then this
> would give
> > you:
> >
> > (ROC - ROC.9) - (ROC.1 - ROC.10)
> >
> > would that give you what you're after?
> >
> > We could also add a SLOPE(token, period) function as well.
> >
> > Chad
> >
> > _____
> >
> > From: LinnSoft@yahoogroup <mailto:LinnSoft% 40yahoogroups. com> s.com
> [mailto:LinnSoft@ yahoogroup <mailto:LinnSoft% 40yahoogroups. com> s.com] On
> Behalf
> > Of quickmail1
> > Sent: Sunday, July 12, 2009 7:49 PM
> > To: LinnSoft@yahoogroup <mailto:LinnSoft% 40yahoogroups. com> s.com
> > Subject: [LinnSoft] Re: RTL 101 Continued... Divergence
> >
> >
> >
> >
> >
> > Chad,
> >
> > REF is helpful in one regard. If I'm not mistaken from your example it
> can
> > be used to give the value of any indicator at a given signal, which I
> hadn't
> > realized. Very nice to know.
> >
> > The other issue is accel/deceleration.
> >
> > Decel/acceleration itself is a difficult thing to calculate accurately
> in
> > Irt because its a very 'relative' indicator. It involves an
> origination
> > point of perhaps, for example, where an indicator's initial movement
> in one
> > direction began, and assessing accel/decel over that dynamic amount of
> time.
> >
> >
> > For example I can create a signal that can identify a rising
> indicator that
> > is decelerating:
> >
> > (ROC-ROC.2)< (ROC.1-ROC. 3) and (ROC.1-ROC.3) <(ROC.2-ROC. 4) and
> > (ROC.2-ROC.4) <(ROC.3-ROC. 5), etc.
> >
> > However this ROC indicator might have been increasing for 20 bars, or
> 200
> > bars or more etc. If its 200, this signal isn't very useful because it
> > accounts for such a small % of its move. If its rising only 20 bars,
> it
> > might be useful, but still notperfect.
> >
> > The volatility of any stock or instrument is always going to be
> different,
> > so the amount of data incorporated into measure accel/deccel of it
> will
> > always need to be different as well.
> >
> > A thought towards a solution is that currently "CI.20" refers to 20
> bars
> > back, but if Irt could understand something like "CI.V#1" to return a
> > desired historical CI bar, a user could set the V# perhaps by employ
> SSTAT
> > (bars since last signal), which could dynamically affect Signal's
> > calculation (or indicator/ci/ scan) to adjust to the particular amount
> of
> > data one wants to evaluate.
> >
> > For a visual, here's a chart I saved a while ago, hopefully not too
> > confusing (admittedly not the greatest example):
> >
> > chart1 <http://www.charthub
> <http://www.charthub .com/images/ 2009/04/08/ Lng2_90m_ d_trd>
> .com/images/ 2009/04/08/ Lng2_90m_ d_trd>
> >
> > On the bottom pane, identifying accel/decel would be helpful for the
> thick
> > navy blue and 'thin black' indicators, (and generally the th! ick red<
> /i>
> > and cyan ones if a larger period of time is used...not so good here
> tho).
> > The relevant 'crossover' events in the initial price reversal downward
> are
> > where the 'magenta' crosses under the 'thick navy blue', and where the
> > 'thick navy blue crosses under the 'thick red'. In either case,
> identifying
> > accel/decel would require accounting for each's widely varying recent
> > movement.
> >
> >
> > John
> >
> > --- In LinnSoft@yahoogroup <mailto:LinnSoft% 40yahoogroups. com> s.com,
> "Chad Payne" cpayne@ wrote:
> > >
> > > John,
> > >
> > > If SSTAT is giving you the "bars since last signal", and you want to
> get
> > the
> > > ROC of that bar that the signal occurred (ROCs crossed in this
> case), then
> > > you can use:
> > >
> > > REF(ROC, SSTAT)
> > >
> > > You could get the value 1 bar before or after that bar with:
> > >
> > > REF(ROC, SSTAT + 1) // gets bar before
> > >
> > > REF(ROC, SSTAT - 1) // gets bar after
> > >
> > > You could get the highest value of ROC since the signal occurred
> with:
> > >
> > > MAX(ROC, SSTAT)
> > >
> > > does that give you the information you need to make this happen?
> > >
> > > Regards,
> > > Chad
> > >
> > > _____
> > >
> > > From: LinnSoft@yahoogroup <mailto:LinnSoft% 40yahoogroups. com> s.com
> [mailto:LinnSoft@ yahoogroup <mailto:LinnSoft% 40yahoogroups. com> s.com] On
> Behalf
> > > Of quickmail1
> > > Sent: Thursday, July 09, 2009 3:54 PM
> > > To: LinnSoft@yahoogroup <mailto:LinnSoft% 40yahoogroups. com> s.com
> > > Subject: [LinnSoft] Re: RTL 101 Continued... Divergence
> > >
> > >
> > >
> > >
> > >
> > > Thanks for the tutorial Chad. Its both and reminder and informative
> for
> > > me.
> > >
> > > Where I get stumped with d/c is looking at data over a dynamic
> amount of
> > > time since a given signal occured (ie crossover of two CI's.)
> > >
> > > For example, I'll use SSTAT to learn that an ROC value of one
> > > periodicity crossed over an ROC value another periodicity "20" bars
> ago
> > > (using 'bars! since l ast signal'). I'll set that result of "20" to
> V#1.
> > >
> > > I then want to begin analyzing movement over time of the two
> indicators
> > > (and/or other indicators and their relationships) starting "20" bars
> > > ago.
> > >
> > > Is there a way to use this V#'s value to reference a specific
> historical
> > > bar's value of any CI at that respective bar? (where a user could
> > > multiply the V# by, for example, .25, .5, .75, and set the results
> to
> > > additional V#'s, to get the values of the CI at 5, 10, and 15 bars
> back
> > > as well.)
> > >
> > > John
> > >
> > > --- In LinnSoft@yahoogroup <mailto:LinnSoft% 40yahoogroups. com>
> s.com,
> > "Chad
> > > Payne" cpayne@ wrote:
> > > >
> > > > I've continued to add contect to the RTL 101 Tutorial each day.
> > > >
> > > > http://www.linnsoft <http://www.linnsoft
> <http://www.linnsoft .com/tutorials/ rtl.htm> .com/tutorials/ rtl.htm>
> > > .com/tutorials/ rtl.htm
> > > >
> > > > This morning, I added an interesting example on
> divergence.. .either
> > > between
> > > > price and an indicator, or between two indicators. Anyone
> interested
> > > in the
> > > > concept of divergence should read through this example. It can be
> > > found at
> > > > the very bottom of the tutorial:
> > > >
> > > > http://www.linnsoft
> > <http://www.linnsoft
> <http://www.linnsoft .com/tutorials/ rtl.htm#Divergen ce>
> .com/tutorials/ rtl.htm#Divergen ce>
> > > .com/tutorials/ rtl.htm#Divergen ce
> > > >
> > > > Regards,
> > > >
> > > > Chad Payne
> > > > Linn Software, Inc.
> > > > <http://www.linnsoft <http://www.linnsoft <http://www.linnsoft .com/>
> .com/> .com/>
> www.linnsoft. com
> > > >
> > >
> >
>