BUG: built-in Slope() method incorrect

[anachronist]

The built-in Slope() method is broken. That is, if it's supposed to be a linear regression slope, it isn't returning correct values. In fact, the built-in Slope() looks noisier than a regression slope of the same period if you plot them both.

The regression slope is given by the code found in the LinReg indicator:

double sumX = (double) Period * (Period - 1) * 0.5;
double divisor = sumX * sumX - (double) Period * Period * (Period - 1) * (2 * Period - 1) / 6;
double sumXY = 0;
for (int count = 0; count < Period && CurrentBar - count >= 0; count++)
   sumXY += count * Input[count];           
double slope = ((double)Period * sumXY - sumX * SUM(Input, (int)Period)[0]) / divisor;

Make an indicator that plots this result, and you'll see it's different from Slope(Input, Period-1, 0);

There isn't source code available for the built-in Slope() method, so I can't debug it. There are faster algorithms, by the way, that don't require execution of a loop on each bar. For example, with Mark Simms and Bob Fulks, we developed a super-fast calculation that reproduces the linear regression slope exactly without executing a loop on each bar. My TradeStation code is here.

If the Slope() method is calculating something other than the slope of a regression line, the documentation should say what that is.
-Alex

[NinjaTrader_JoshP]

Slope() is not a Linear Regression Slope. It is simply slope of whatever DataSeries you force it upon.

[anachronist]

Slope() is not a Linear Regression Slope. It is simply slope of whatever DataSeries you force it upon.

A linear regression slope is also simply the slope of whatever DataSeries goes into it! This has always been the case. See, for example, the source for LinReg.

And how is Slope() calculated, if not by linear regression?

I find it disturbing that (a) the result isn't what one expects, and (b) the algorithm for determining the slope is not disclosed anywhere.

This is especially disturbing because I have seen examples of code that assume it's a regression slope.

-Alex

[NinjaTrader_JoshP]

Slope() is for a broader use than just linear regression. You are not limited to only running on OHLC DataSeries. Slope() was never intended to be lin reg slope. If you look at the example provided in the Help Guide it shows it being used on an SMA. Running Slope() on LinReg() will not suffice either simply by looking at the LinReg code.

Value.Set(intercept + slope * (Period - 1));

What you were trying to get was the value of "slope", but you are running an extra layer of Slope() calculations on top so it will of course be different than the "slope" value. Now there may be certain conditions (parameter settings or what not) that can allow for them to overlap and produce the same results, but I have not entertained this thought in tests.

You are always free to make your own algorithm for Slope() too. Just create yourself an indicator with whatever algorithm you see fit and call that instead of the Slope() method.

[anachronist]

I feel like we're going in circles here.

I know how to calculate a regression slope. I have written my own algorithms to do so, and already posted it to the file sharing area.

Nowhere did I suggest that Slope() should be run on LinReg() (although that's what the original LinRegSlope indicator in the file sharing area does). Yes, you can run Slope() on any data series, so what? You can write a regression slope algorithm to do the same thing... and when you do, a comparison with the output of Slope() will clearly show that Slope() gives erroneous results.

I am using the term "regression" in its general, mathematical sense, not in the restricted sense of an operation on OHLC prices. We're both referring to the slope of an arbitrary DataSeries. That's the point. Slope() returns incorrect values.

My question is, if Slope() isn't a regression slope, what is it? What, exactly, is it calculating? The answer is not "it's calculating the slope." I know of only one way to determine the slope of a data series, and that's the slope of the best-fit line, and that best fit line is determined by a least-squares calculation, which is a linear regression.

Slope() isn't doing that. What other definition of "slope" can Slope() using? It's doing something, but what's coming out isn't slope.

-Alex

[NinjaTrader_Dierk]

Slope returns this:

return (series[endBarsAgo] - series[startBarsAgo]) / (startBarsAgo - endBarsAgo)

[anachronist]

Slope returns this:

return (series[endBarsAgo] - series[startBarsAgo]) / (startBarsAgo - endBarsAgo)

That's it? Momentum divided by the interval length? That's hardly what I'd call a slope. It would return zero for the series 0,1,0,-1,0, which is incorrect because such a series clearly has a downward slope.

The documentation for Slope() says it returns the slope of a line. I guess this is ambiguous because it doesn't say what line. When someone sees a method called "Slope()" with a DataSeries input, it's assumed that it returns the slope of the DataSeries values. That's the slope of a linear regression line.

It seems there's still a problem that needs fixing, either in the documentation, or in the method:

• Clarify the documentation to explain what Slope() actually does; that is, it returns the difference between the first and last value divided by the interval length. It doesn't actually return the slope of a regression line. This is the "easy" way to fix the problem.
• Or, fix Slope to return the slope of a linear regression line. This is the most useful and meaningful result, and would be preferred, but not strictly necessary because anyone can implement their own custom method.

What's the point of having a built-in method that does something trivial, equivalent to one simple line of code? Why even offer that? The slope of a regression line is non-trivial. That would be more useful as a built-in method.

-Alex

[NinjaTrader_Dierk]

That's what the majority of users requested. However, thanks for your suggestion. We'll add it to the list of future considerations.

[anachronist]

Well, new users of NinjaTrader won't know about any past consensus concerning what Slope() should return.

To prevent further issues with this, at least fix the documentation to explain what Slope() really does. That would make sure folks don't mis-use it. I've run across examples that assume Slope() returns an actual slope of a regression line. The ambiguity of the documentation creates confusion.

Thanks.
Alex

[NinjaTrader_Dierk]

Thanks for making us aware. We'll reflect that in the docs.

[steveg]

At the risk of appearing really simple, would appreciate your assistance in determining the slope of a 34 EMA line with the results in ticks. My understanding of slope is "rise over run". I compare the "price" (x axis) of the EMA line at one point and the same ten bars away. I don't care that the result is positive or negative; I can see the line. The important data to me is the number of ticks: the higher the number, the steeper the slope. Thanks

[NinjaTrader_JoshP]

steveg,

I do not understand what you mean by ticks. Slope is a mathematical term either provided in radians or degrees (in NT's Slope() case it is radians). There is no concept of "ticks". The closer you are to pi/2 or 3*pi/2 the steeper the line.

[steveg]

Slope

To clarify the term "ticks": I'm referring to whatever single change the chart reflects on the X axis. For example: a stock that trades in minimum dollar increments, one tick would be $1; the TF (Russell emini) trades in 1/10 of one point, that 0.1 would be one tick; the NQ (Nasdaq emini) trades in 1/4 of one point, that .25 would be one tick. I hope I've made myself clear. Thanks for your attention.

[NinjaTrader_JoshP]

steveg,

I understand what tick means, but I do not understand what you want from it in the context of slope. What it sounds like you are just looking for a difference between one bar and the next bar. You could just do something like Close[0] - Close[1]. Maybe I am not understanding.

[mgbloomfield]

Sounds like your formula is Ticks / Periods

(Close[0] - Close[1]) / 2