Reversal indicator (actual, not predictive)

[shane]

I think I've seen this before, but not sure where. I am looking for a
reversal indicator, that shows the strength of a reversal. Not
looking for something that is predicting a reversal, but shows the
actual strength of the reversal as it's happening or shortly
thereafter. It's okay to have some lag. Does anyone here know of
anything like this?

Shane

[ShaggsTheStud]

Not exactly sure what you are looking for, but I tend to write things like this:

1) When the velocity of a signal is positive, wait for its acceleration to turn negative
2) When the velocity of a signal is negative, wait for its acceleration to turn positive

I "roll my own" because I generally have a good idea of how I want this to work, so I write the indicator from scratch.

For a basic start, I start with an oscillator (velocity is an oscillator, because it oscillates between a positive and negative value), that has a "long" time period.

Then my acceleration is based on doing two "short" time period EMA's, one much shorter than the other.  Positive or negative velocity is determined by subtracting one from the other.  There are other ways of doing this as well, such as comparing the value now to the value X seconds ago.  Also the underlying EMA's could be based on the velocity signal, or something else, whatever it is that has suddenly reversed. 

You want the "velocity" to have much longer averaging value, so that a "strong" trend remains as a relatively large value, even once the trend starts to reverse.  The acceleration is trying to figure out when this velocity is changing direction, so it should be much shorter time period.

From there you can figure out the strength or validity of a reversal by putting some conditions on it.  If you want to look for a strong trend, then only pay attention when the velocity is large.  When you want a strong reversal, look for large acceleration.  To keep the size of the reversal relative to the size of the trend, look for large acceleration/velocity.

I hope this is helpful to someone.

--
You received this message because you are subscribed to the Google Groups "JBookTrader" group.
To post to this group, send email to jbook...@googlegroups.com.
To unsubscribe from this group, send email to jbooktrader...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jbooktrader?hl=en.

[Eugene Kononov]

Not exactly sure what you are looking for, but I tend to write things like this:

1) When the velocity of a signal is positive, wait for its acceleration to turn negative
2) When the velocity of a signal is negative, wait for its acceleration to turn positive

I did the same thing. There seems to be a clear motivation for this. For example, as can be seen from the performance charts, it appears that good short entries can be made when balance velocity reaches a low negative value and is starting to accelerate up. Conversely, good long entries can be made when balance velocity reaches a high positive value and is starting to decelerate down. However, adding acceleration to my velocity indicators did not improve the overall performance of my strategies. Perhaps I am not calculating acceleration quite right. Shaggs, would you be willing to post your own version of the indicator? Thanks.

[ShaggsTheStud]

For balance velocity (this may be unchanged, not sure):

    public BalanceVelocity(int fastPeriod, int slowPeriod) {
        addParam(new Integer(fastPeriod));
        addParam(new Integer(slowPeriod));
        fastMultiplier = 2.0 / (fastPeriod + 1.0);
        slowMultiplier = 2.0 / (slowPeriod + 1.0);
    }

    @Override
    public void calculate() {
        double balance = marketBook.getSnapshot().getBalance();
        fast += (balance - fast) * fastMultiplier;
        slow += (balance - slow) * slowMultiplier;

        value = fast - slow;
    }

And for acceleration I made a different indicator:

public class BalanceVelocityDerivative extends Indicator {
    private final double balFastMultiplier, balSlowMultiplier, velFastMultiplier, velSlowMultiplier;
    private double balFast, balSlow;
    private double velFast, velSlow;

    public BalanceVelocityDerivative(int balanceFastPeriod, int balanceSlowPeriod, int velocityFastPeriod, int velocitySlowPeriod) {
        addParam(new Integer(balanceFastPeriod));
        addParam(new Integer(balanceSlowPeriod));
        addParam(new Integer(velocityFastPeriod));
        addParam(new Integer(velocitySlowPeriod));
        balFastMultiplier = 2.0 / (balanceFastPeriod + 1.0);
        balSlowMultiplier = 2.0 / (balanceSlowPeriod + 1.0);
        velFastMultiplier = 2.0 / (velocityFastPeriod + 1.0);
        velSlowMultiplier = 2.0 / (velocitySlowPeriod + 1.0);
    }

    @Override
    public void calculate() {
        double velocity;
        double balance = marketBook.getSnapshot().getBalance();
        balFast += (balance - balFast) * balFastMultiplier;
        balSlow += (balance - balSlow) * balSlowMultiplier;

        velocity = balFast - balSlow;
       
        velFast += (velocity - velFast) * velFastMultiplier;
        velSlow += (velocity - velSlow) * velSlowMultiplier;
       
        value = velFast - velSlow;
    }

    @Override
    public void reset() {
        balFast = balSlow = velFast = velSlow = value = 0;
    }
}


I set the velocity fast and slow periods to be much smaller than the balance periods (which I think are the same periods I use for the first indicator). 

As a general rule of thumb I set all the periods short enough that the trends make sense when I look at them in the graph window.  Some of the example strategies have the periods set so long that they don't make any sense when I look at them! (Although they still yield profitable results...)

Anyways, I made a strategy that makes good profits using the techniques we just talked about, but only on the long side in the example data.  Short side is not so good. (I tend to split strategies into two parts, a long strategy, and a short strategy, and I optimize them independently.)

--

[Eugene Kononov]

My code is virtually identical. In the optimization runs, I tried:

a) using velocity only
b) using acceleration only
c) using both velocity and acceleration

All options provide decent results, but b) and c) do not seem to add any extra edge to a).

[ShaggsTheStud]

These different methods may yield better performance for certain exit conditions.  Just throwing that out there...

[Eugene Kononov]

On Sat, Dec 4, 2010 at 5:09 PM, ShaggsTheStud <shaggs...@gmail.com> wrote:

These different methods may yield better performance for certain exit conditions.  Just throwing that out there...

What kind of exit conditions do you have in mind?

[ShaggsTheStud]

No idea.  It's just something to keep in mind while strategizing - just because something doesn't work as well for this application, it might be a stellar success in something else, so don't just give up on ideas forever.