Average Directional Movement Index (ADX)

[DaveSkender]

Community discussion about Average Directional [Movement] Index (ADX)

[bobtabor]

Is there an equivalent indicator focused on volume? Or any indicator where I can simple see whether volume is increasing or decreasing over, say, the last 5 or 10 minutes?

[DaveSkender]

If you're looking for something like ADX, Price Volume Oscillator is an interesting one to explore.

Generally, there are a few indicators in the library that use volume:
https://dotnet.stockindicators.dev/indicators/#volume-based

The simplest is merely a moving average of volume, where you can compare current price to the rolling average (over or under).

[DaveSkender]

Slope of volume might interesting too.

[bobtabor]

re: slope

Yes, that is what I am doing now. I was hoping to translate slope into something more meaningful because I can't make sense of the values other than "positive" or "negative".

I was doing this to turn the slope into degrees, hoping it could help me visualize the extent of the upward or downward momentum. This is what I was doing:

var result = LinearRegression.Calculate(points);
var degrees = Math.Atan(result.Slope) * (180.0 / Math.PI);

But in one case, I was getting a -89 ... it was then I realized that the scale is important when considering slope. :/

[DaveSkender]

Yah, might be easier to do the slope of a small moving average to filter the noise.

[tgvolk]

this may help converting slope to degrees. Figure an average size monitor (results may vary), but I can get close to the correct degrees with this:

var slopeAdjustment = (zedGraphControl1.GraphPane.YAxis.Scale.Max - zedGraphControl1.GraphPane.YAxis.Scale.Min) / (numPer * .25);
var degrees = (Math.Atan(currentSlope / slopeAdjustment ) * (180 / Math.PI);

[DaveSkender]

It's a bit of a tangled mess when you get into the circular logic needed to get the geometry right. I tried once, but gave up after a while as it wasn't worth the effort for my use case.

It all gets back to the aspect ratio of your chart plot, how many bars of data you're showing, and the axis scales. Throw in responsive user interface design and it pushes you towards an entangled software architecture where the data tier relies on the user interface tier.

With that said, I think it's possible, but you'd probably need to either enforce fixed values for: chart aspect ratio, chart axis size, and number of bars plotted; or, let the user interface dynamically calculate % values as the screen size changes.

[hal9000cc]

I discovered a very strange thing. ADX on binance does not use TR/ATR in the calculation. Your indicator also does not use TR/ATR in calculating the ADX value and the result is the same as binance. But in all the sources that I found, the algorithm is different. It uses TR or ATR.

[hal9000cc]

Yes, what proofs, ordinary school algebra.
(A / X - B / X) / (A / X + B / X) = ((A - B) / X) / ((A + B) / X) = (A - B) / (A + B)

I think we are not counting correctly, so TR is being reduced. I don't think Wilder couldn't cut a simple formula :)

We calculate like this:
p_di = ma_calculate(p_dm, period, ma_type_enum) / tr
m_di = ma_calculate(m_dm, period, ma_type_enum) / tr

I will assume that it is necessary so:
p_di = ma_calculate(p_dm / tr, period, ma_type_enum)
m_di = ma_calculate(m_dm / tr, period, ma_type_enum)

In this case, nothing is reduced.
I don't have access to the original source to verify this. I'll keep the second option for myself.

[hal9000cc]

But I have doubts. If you have a link to the original source, I will be grateful for it.

[DaveSkender]

He uses TR to normalize the positive and negative incremental directional movements, DI+ and DI-. These are separate but still useful data elements. With your simplification the red and green lines in this family of indicators would be denormalize (not aligned with author’s intent).

[DaveSkender]

Wilder describes this in his book “New Concepts in Technical Trading Systems”. It’s an actual book, so I can’t send you a link.

[DaveSkender]

If you want to save yourself some time, consider just using our Python wrapper. We've done all this work for you.

[hal9000cc]

Good day!
I can't figure out how the moving average is calculated. Adx.Series.cs:

            if (i == lookbackPeriods)
            {
                trs = sumTr;
                pdm = sumPdm;
                mdm = sumMdm;
            }
            else
            {
                trs = prevTrs - (prevTrs / lookbackPeriods) + tr;
                pdm = prevPdm - (prevPdm / lookbackPeriods) + pdm1;
                mdm = prevMdm - (prevMdm / lookbackPeriods) + mdm1;
            }

Are you sure it shouldn't be like this?

            if (i == lookbackPeriods)
            {
                trs = sumTr;
                pdm = sumPdm;
                mdm = sumMdm;
            }
            else
            {
                trs = prevTrs - (prevTrs / lookbackPeriods) + (tr / lookbackPeriods);
                pdm = prevPdm - (prevPdm / lookbackPeriods) + (pdm1 / lookbackPeriods);
                mdm = prevMdm - (prevMdm / lookbackPeriods) + (mdm1 / lookbackPeriods);
            }

[hal9000cc]

Now I thought - what will be the difference between the curves, if there is an additional division or not. But in fact it does not affect their shape. Only the amplitude and location will change.

[hal9000cc]

Yes, you are right, you have fully implemented the author's method. And there it is considered peculiar. Although, in fact, it is the same ATR, only, it seems, just multiplied by the period.

[DaveSkender]

Dividing TR₁ by a size factor here is eventually going to move TR₁₄ to a smoothed average of TR. If this were intended to be ATR, that would be correct. This is supposed to be "total True Range", not "average True Range", so it'd be something else.

And simply multiplying ATR by lookbackPeriods to reconstitute it to total TR is a bit backward, but I'm sure is a hack some have used. I can't do the math in my head, but it may produce a very similar but still deviant result.

[hal9000cc]

There's another interesting point. All three values count that way. And they are all affected by this effect, and they are divided into each other.
As a result, after a while they begin to completely coincide with my values, which I calculated using the usual MMA smoothing. Here are the last 10 yours and mine:
'''
(array([ 4.31273032, 2.69024009, 9.05587651, 2.55794453, 1.09489647,
0.63638118, 7.9565679 , 8.11709597, 4.41693475, 12.82305828]),
array([ 4.31273032, 2.69024009, 9.05587651, 2.55794453, 1.09489647,
0.63638118, 7.9565679 , 8.11709597, 4.41693475, 12.82305828]))
'''

[DaveSkender]

I'm sure it's possible to reorganize the maths on this one to arrive at the same result.
If you're building your own version of this, instead of using this library, It's up to you to determine if alternative approaches are appropriate for your use cases.

My preference is to be as unopinionated as possible with this library, which is why I always go back to the original authors and never use other people's code or less reputable sources.

[hal9000cc]

First 20 values (up - my):

(array([        nan,         nan,  0.        ,  0.        ,  0.78914315,
       84.37151483, 65.44538665, 44.95463786, 33.39600899, 24.98930754,
       16.28827223,  7.58056838,  4.00331537, 25.41011753, 15.4902397 ,
       13.50497211, 19.72029074, 12.84137277,  5.74302962, 14.39915213]),
array([        nan,         nan,  0.        ,  0.        ,  0.86371074,
       85.083874  , 65.73148531, 45.08944494, 33.47034823, 25.02843565,
       16.30488697,  7.58416513,  4.00431825, 25.41363659, 15.49154739,
       13.50554353, 19.72076957, 12.84153667,  5.7430624 , 14.39918878]))

[DaveSkender]

Hehe, sounds like you're on a mission 😄

[DaveSkender]

There's 2 things to consider with the starting values. 1) we're using a zero-based index, so lookbackPeriods - 1 is actually the same bar position as lookbackPeriods and 2) The first TR can only be calculated on the second bar; therefore, the first SMA of TR, the seeded value of TR₁₄ can only happen on the 15th bar, for example. Our manual calculations spreadsheet might illuminate some things here for you.

[hal9000cc]

It seems to be ok everywhere. Perhaps I am not initializing correctly, I will search.

[hal9000cc]

I found out the reason. My ATR is counted separately, and initialized one step earlier. You are calculated in exact accordance with the original method.

[DaveSkender]

On a related note, check that you’re using v2.4.1 or newer. I’d recently updated all True Range related indicators so they don’t try to calculate TR on the first bar with limited information. Williams is inconsistent about whether or not this is a good idea. The change did impact ADX, by shifting the first calculable bar by one position.

In other words, since you’re eagerly trying to find problems, I’ll give you partial credit for finding:

There is an assumption. It looks like you have at the beginning the sum is not lookbackPeriods

However, most credit goes to a different conversation with @mihakralj.