Slope of an indicator, frustrating =/

October 9th, 2012, 03:38 PM

LOL. Thanks for sharing. I had completely forgotten about that one. It was a nice reminder. :-)

April 6th, 2015, 01:11 PM

Zeos6

Actually, it is possible to do the slope calculation the way you want. You just need to convert to actual distances in inches and take the ratio. The distances can be obtained from the screen resolution via a Graphics object.

@Zeos6 do you have an example code for this Graphics Object that I could use as take-off?
I have an angle indicator that is based on a slope and it does work very similar to "Momentum", it does require some "manual override" though, lol .
I am just curious because I am thinking of another application in Ninja.

April 7th, 2015, 01:06 PM

Hello ElChacal,

I am not sure what you are trying to implement, or how you are implementing this but here it goes ...
If you need more info, please let me know.

1. Somewhere you need to have created a Graphics object. If you are overriding the Plot function, Graphics is the first parameter passed to it. It is called graphics. If you are doing this outside of the Plot function, then you can declare a Graphics object in the Variables section of your code as follows:

Code

private Graphics g;	// Declare a Graphics object.

You will also need to override the OnTermination() method to dispose of it as follows:

Code

protected override void OnTermination()
{
     base.OnTermination();
			
     // ... Clean up the Graphics object.
     g.Dispose();
}

You now have a graphics object available. Now suppose you wanted to calculate the slope between the High of two consecutive bars, the current bar and the previous bar, ...

Code

double currentBarHigh = Bars.GetHigh(CurrentBar);                                            // get CurrentBar Y value
int curentBarY = this.ChartControl.GetYByValue(BarsArray[0], currentBarHigh);  // get the Y value of current bar in px
int curentBarX = this.ChartControl.GetXByBarIdx(BarsArray[0], CurrentBar);      // get the X value of current bar in px

double previousBarHigh	= Bars.GetHigh(CurrentBar-1);
int previousBarY = this.ChartControl.GetYByValue(BarsArray[0], previousBarHigh);
int previousBarX = this.ChartControl.GetXByBarIdx(BarsArray[0], CurrentBar-1);

double verticalSize		= (double)(currentBarY - previousBarY)/((double)g.DpiY);	// in inches
double horizontalSize      = (double)(currentBarX - previousBarX)/((double)g.DpiX);	// in inches

double slope = verticalSize/horizontalSize;

(I have done this quickly, from memory, so I hope there are no errors.)

Note that the slope you calculate will depend on how the chart is scaled. If you stretch the chart, the slope will be different than if you compress the chart. This is the same as if you were doing the slope calculation on a chart printed on paper.

April 7th, 2015, 01:48 PM

@Zeos6 Thanks!

I was actually planning on placing a 45 deg grid behind the bars, not sure how this will help my trading though, LOL.

With regards to the slope/angle scaling I found very useful to divide by ATR to have a normalized/fixed y axis. I think my Angle indicator probably helps me more. The grid probably throws more dirt into the charts.

Thanks!!

April 7th, 2015, 02:06 PM

Hi,

If you simply want to place a 45 degree line behind your visible bars, just use the the canvas coordinates instead of CurrentBar and Previous bar. Use the bottom left canvas coordinate for +45 degree line and top left canvas coordinate for -45 degree line. Clearly for 45 degrees your delta y = delta x. I am sure you can figure it out.

As an aside, I am intrigued by your thinking of using ATR to "normalize" the y axis. if you don't mind me asking, what is your reasoning for this. If I recall correctly, the ATR is based on a period length. Why would this normalize the y-axis values?

April 7th, 2015, 03:03 PM

@Zeos6 it is because I am dividing to the # of bars in the 'x' axis so I need to scale to "bars" sort of speak to see a value in degrees that makes more sense.

For instance, a very small difference in "6A" of a few cents vs. a larger difference of dollars in "ES" over the last 3 bars and converted to degrees will yield a value out of order because (3) bars (or the number "3") is too large of an x axis scale for the 6A and too small of an axis for the ES.

For instance:

In 6A = (0.7651 - 0.7640)/3 *180/pi() = 0.017189
In ES = (2044 - 2040)/3 *180/pi() = 76.39

When I divide it let's say by ATR(50) I "normalize the y axis" and get a result more "degrees oriented" in lack of a better term. The shape of the curve is the same but the values are now "scaled to bars".

ATR(50) of 6A ~ 0.00109
ATR(50) of ES ~ 2

In 6A = (0.7651 - 0.7640)/3 *180/pi() / 0.00109 = 15.77 deg.
In ES = (2044 - 2040)/3 *180/pi() /2 = 38.19 deg.

I guess that what you proposed of normalizing to inches is probably a more accurate way of doing it. At the end of the day if I am focused on the cross through zero, not much of a difference.

April 7th, 2015, 03:47 PM

I understand what you are thinking of doing but I would take a different approach. The issue, from what I understand, seems to be one of 'equivalency" between charts of different instruments. What I would do would be to calculate the aspect ratio of each instrument chart in inches and scale one instrument by the ratio of the aspect ratios to make it comparable to the other instrument. I would think that that would be more accurate.

So using your instruments, I would compute the delta y/deltax for ES based on a value of $100 for the vertical axis:

ES: $50 per point, $12.50 per tick
6A: $100 per point, $10.00 per tick

Compute delta y using 2 points for ES ($100) and again compute delta y using 1 point for 6A. Convert these delta y values to inches.
Next, compute delta x, the time span across say 10 bars, on ES and likewise compute delta x for the same number of bars (10) on 6A. Convert these delta x values to inches. Now compute the delta y/delta x ratios for ES and for 6A.

You can now use those ratios to "correct" your slope calculations. For example, you can "correct" your 6A slope to match the shape of your ES chart, or vice versa. What this would do in effect is give you the slope of 6A if the 6A chart was scaled exactly like your ES chart. Now you can compare the slopes more correctly.

Please note that I am not sure exactly what you are trying to accomplish in the big picture, so this may not necessarily be the best approach to do what you ultimately want to do.

November 18th, 2015, 04:30 PM

Some time ago I was looking for a way to measure the slope of a line in NinjaTrader and read various threads about it on this forum. The issue, of course, is when you look at a line on your chart, it has one slope, and when you resize the chart the slope will change.

That approach, of measuring the slope of a drawn line is the wrong way to go at the problem.

If you take price on the starting bar, the price on the ending bar and the starting price on the ending bar as a right triangle, you can calculate the hypotenuse using trig functions that are built into C#. The angle you get does not change when the chart is resized, as it's based on chart values, rather than eyeball values.

Assuming people are usually wanting to know when price isn't going anywhere, to avoid trading chop, I have made an indicator that calculates the angle, in degrees, of the Regression Channel midline. You can set the Regression Channel parameters, period and width, as usual, and you get a plot in a new panel showing the angle, between +90 and -90. Since it's in degrees, it's fairly common sensical.

You can review a chart, with the plot, tweak the period and width till what you want to consider chop is within X degrees of a zero slope, then tell your automated system, or your self, not to trade when the angle is between +X and -X.

Here's the link:
https://nexusfi.com/local_links.php?linkid=1682

I hope some of you find this indicator of use.

November 21st, 2015, 02:06 PM

DavidBodhi

Some time ago I was looking for a way to measure the slope of a line in NinjaTrader and read various threads about it on this forum. The issue, of course, is when you look at a line on your chart, it has one slope, and when you resize the chart the slope will change.

That approach, of measuring the slope of a drawn line is the wrong way to go at the problem.

If you take price on the starting bar, the price on the ending bar and the starting price on the ending bar as a right triangle, you can calculate the hypotenuse using trig functions that are built into C#. The angle you get does not change when the chart is resized, as it's based on chart values, rather than eyeball values.

Assuming people are usually wanting to know when price isn't going anywhere, to avoid trading chop, I have made an indicator that calculates the angle, in degrees, of the Regression Channel midline. You can set the Regression Channel parameters, period and width, as usual, and you get a plot in a new panel showing the angle, between +90 and -90. Since it's in degrees, it's fairly common sensical.

You can review a chart, with the plot, tweak the period and width till what you want to consider chop is within X degrees of a zero slope, then tell your automated system, or your self, not to trade when the angle is between +X and -X.

Here's the link:
https://nexusfi.com/local_links.php?linkid=1682

I hope some of you find this indicator of use.

Your approach will not work. The problem here is that the angle that you have to use will depend on the chart type select and on the instrument selected. So you have to find out the appropriate angle for each instrument and timeframe. With this restriction portfolio backtesting becomes impossible, as each instrument will needs it own angle.

What you need to do is to normalize the steepness. This means you need to move away from all geometrical concepts and trigonometric functions and understand that slope is just a visual proxy for momentum. Go back to momentum or rise over run, and calculate the average momentum over a period of N bars. In a second step you need to put that average momentum in relation to volatility. Ticksize is no good proxy for volatility, but the average true range certainly is.

All you need to do is to divide the average momentum by the average true range. When momentum is high compared to intra-bar volatility, this is a steep move. When it is low compared to intra-bar volatility, it is a weak move.

All technical traders who have come up with geometrical concepts have basically failed. That includes that square of nine stuff as well as the Polarized Fractal Efficiency (what a fancy name for a piece of misapplied geometry). Just look for the average momentum (as William Blau did for his indicators) and compare to volatilitily, and you have a sound concept that you can use across all instruments and timeframes and that is fit for portfolio backtesting as well.

November 21st, 2015, 03:06 PM

I understand that you've been involved in trading and charts and indicators for a lot longer than I, but the math I am looking at is what's in the linear regression indicator, which does work.

My use of TickSize was simply an attempt to get to 'units' of rise or fall. Doesn't matter what the units are, really. And I don't need this thing to be any more specialized than the Linear Regression indicator that came with NT.

Definitely, as you say, rise (or drop) over run, which is 'units on y axis' over bars of whatever kind (units on x axis) is the way to go.

I confess, I wasn't thinking about what kind of bars one would use when I started this, but ultimately the question IS the slope of the hypotenuse of a right angle triangle, up or down, regardless what kind of bars you're using, and the value should stay the same regardless how a chart is resized. To that extent, it is a question of geometry abstracted from how it's displayed to the eye.

I don't see how change of instrument impacts this at all. It's still going to be units up/down over bar units.

At the moment, only thinking about it for 5 minutes, I can't think of a bar type that doesn't go up or down by ticksize. Just ones that change bar units from time to volume or change-in-price. But I'll think about it more.

I'll have to consider your comment about momentum and volatility. So far, I have not been satisfied with those indicators, so I'm not sure that's where I'd want to go. But you may have brought them up as part of making an indicator applicable to any bar type.

I won't worry about making the indicator universally applicable till I satisfy myself that the indicator shows a zero slope when price doesn't change, an increasingly positive one when price rises more steeply and an increasingly negative one when it falls more steeply. After that, I'll worry about alternate chart types.

Slope of an indicator, frustrating =/

Discussion in NinjaTrader

Slope of an indicator, frustrating =/