Are there any methods to get the angle of a trendline?

[Hapu Arachchilage Tharindu Lakmal]

I have drawn a trend line in the bellow chart. I want to know the angle of this trendline so I can use it to trade based on some other conditions. but I don't know how to calculate it. do you have any idea how to do this. I don't need you to code for me. give me an idea how to do this. Your help is appreciated. :-)

 

[Fabio Cavalloni]

Angle meant in degrees is meaningless: it depends on the chart scale and it's only a visual thing which depends also on the screen resolution.

What I considered the best way to calculate the "angle" is to compare the difference of 2 values compared to the average range (simply the ATR of the chart timeframe). This value do not depends on the chart scale and it's a consistent value you can use for your consequent considerations...

[William Roeder]

Hapu Arachchilage Tharindu Lakmal: . I want to know the angle of this trendline

Can't be done.

1. There is no angle from 2 anchor points. An angle requires distance divided by distance; a unit-less number. A chart has price and time. What is the angle of going 30 miles in 45 minutes? Meaningless!

2. You can get the slope from a trendline: m=ΔPrice÷ΔTime or m=ΔPrice÷Δ(bar index). Changing the price scale, bar width, or window size, changes the apparent angle, the slope is constant. Angle is meaningless.

3. You can create an angled line using one point and setting the angle (Object Properties - Objects Constants - Standard Constants, Enumerations and Structures - MQL4 Reference.) The line is drawn that angle in pixels. Changing the axes scales does NOT change the angle (and thus is meaningless.)

4. If you insist, take the two price/time coordinates, convert them to pixel coordinates and then to apparent angle with arctan.
             How to get the angle of a trendline and place a text object to it? - Trend Indicators - MQL4 programming forum - Page 2

[Imre Sopp]

I personally also believe that calculating the angle is a pointless extra cost. The slope of the trend line X and Y should be sufficient, its value can be directly compared in the context of trading. Without the use of arctangent and pi. slope = priceDifference / timeDifference and it's as simple as that.

[Conor Mcnamara]

the software understands x and y values on the actual chart, and there is a function in the API which allows you convert time and price into the XY, so you can definitely do something with that:

https://www.mql5.com/en/docs/chart_operations/charttimepricetoxy

note that there is also the reverse... "ChartXYToTimePrice " so you can get back to time and price...these functions seem useful for your use case

[Ryan L Johnson]

This is an interesting discussion.

Let's assume that time/price point A appears first in time, and time/price point B appears second in time, each at different price bars. We can say that a 360-degree circumference of chart area surrounds time/price point A. Designating the point positions where point A and point B are absolutely horizontal (dead flat) in relation to each other as 90-degrees, we have assigned meaning to the otherwise meaningless. In this scenario, both a reading of 0-degrrees and a reading of 180 degrees and above are impossible because bars only print forward in time (and because this example excludes the possibility of point A and point B appearing at the same bar).

It could be more intuitive to designate dead flat as 0-degrees, any upward slant as positive degrees, and any downward slant as negative degrees.

For an indicator wherein the user inputs their own bars and degrees and the indicator implements its own degrees calculation (not either of above), see:

Code Base

Custom Angle Trendline

Dark Ryd3r, 2021.06.08 22:23

Sometime we have to work with Custom Angles based trendline for price action analysis e.g. 45 degree angle is considered more important for up or down trend. This indicator will help you by drawing a trendline which will match your custom angle on last input number of bars

[Imre Sopp]

This is an interesting topic, it would be interesting to hear how you actually deal with such y and x ratio calculations and solve the problem of scaling more extreme data such as very small delta values ? I also propose a real simple solution , please refute or confirm.  I suggest that y delta should be calculated as a percentage of price movement to fit into any scale like this: delta_Y = ((second_Y - first_Y) / first_Y * 100.0) * 100;  Now if we need human readable and directly usable output from this relationship, it is reasonable to use: MathArctan(delta_Y / (second_time - first_time)) * 180.0 / M_PI;

As an output, of course, we don't get a real angle with degrees but we get a functional relation that should express the real Y and X relation even in extreme situations. Maybe there is something more reasonable to implement here for a stable result ?

 

[Ryan L Johnson]

Imre Sopp #:

This is an interesting topic, it would be interesting to hear how you actually deal with such y and x ratio calculations and solve the problem of scaling more extreme data such as very small delta values ? I also propose a real simple solution , please refute or confirm.  I suggest that y delta should be calculated as a percentage of price movement to fit into any scale like this: delta_Y = ((second_Y - first_Y) / first_Y * 100.0) * 100;  Now if we need human readable and directly usable output from this relationship, it is reasonable to use: MathArctan(delta_Y / (second_time - first_time)) * 180.0 / M_PI;

As an output, of course, we don't get a real angle with degrees but we get a functional relation that should express the real Y and X relation even in extreme situations. Maybe there is something more reasonable to implement here for a stable result ?

 

Continuing this interesting thought experiment... One could take time out of the equation completely by attaching such an indicator to a Renko chart, or implementing a semi-logarithmic scale (y axis) in the indicator.

[Conor Mcnamara]

wouldn't it be valid to only do the computation on X and Y? for example, use ChartTimePriceToXY on the two trend line coordinates and then:

double angleRadians = MathArctan((double)(y2 - y1) / (x2 - x1));
double degrees = angleRadians * 180.0 / M_PI;

what you should know though... In MQL5, the Y-axis is inverted, higher prices have lower Y values in screen coordinates

Do some tests with OnChartEvent and you will see what I mean

https://www.mql5.com/en/docs/constants/chartconstants/enum_chartevents

so because of the fact that higher prices have lower Y values and lower prices have higher Y values, you may need to alter the equation for calculating the slope

double angleRadians = MathArctan((double)(y1 - y2) / (x2 - x1));

[Ryan L Johnson]

Conor Mcnamara #:
wouldn't it be valid to only do the computation on X and Y? for example, use ChartTimePriceToXY on the two trend line coordinates and then:

what you should know though... In MQL5, the Y-axis is inverted, higher prices have lower Y values in screen coordinates

Do some tests with OnChartEvent and you will see what I mean

https://www.mql5.com/en/docs/constants/chartconstants/enum_chartevents

so because of the fact that higher prices have lower Y values and lower prices have higher Y values, you may need to alter the equation for calculating the slope

Just to clarify, I was speaking in terms of raw time and price data and not in terms of x nor y pixel coordinates. I was abstractly/scientifically referring to x as the horizontal scale of any 2-dimensional chart, and y as the vertical scale thereof. As usual, there are 1000 ways to do the same thing in MQL5.

[Imre Sopp]

I'm afraid it's not a good idea to link price and time directly to pixels. Consider the difference: on the M1 scale, we analyze movements in detail, whereas on the MN1 scale, the same movement from M1 might be reduced to a barely noticeable dot. Moreover, the goal isn’t to determine angle degrees just by looking at an indicator line. As humans, we naturally perceive and interpret angles visually without even knowing math at all. More importantly, the y/x ratio is primarily useful for optimization and machine learning, where it operates in the background without requiring graphical visualization. So, from my perspective, the key objective is to assess the potential effectiveness of the y/x ratio in enhancing data processing logic. Or it could simplify (or in some cases even replace) the need for separately analyzing the x and y components.

Let's clarify the topic a bit and, from now on, refer to price differences as delta Y and time differences as delta X. As we know, when calculating angles using MathArctan or MathArctan2, the assumption is that we are using a Cartesian coordinate system where the inputs should be on the same scale and normalized. For example, let's say we are trading Dogecoin, which experiences significant price movements over a 5-minute period, resulting in a delta Y of 0.05. Meanwhile, when trading BTC, we might see similarly large movements over the same period, but the delta Y could be 15,000. Let me demonstrate...

void angle_progression()
{
   double delta_y = 0.001; // starting value of delta Y (y1 - y2 = 0.001)
   int    delta_x = 300;   // constant time 5 minute 

   for (int i = 0; i < 10; i++)
   {
      double angle = MathArctan(delta_y / delta_x) * 180.0 / M_PI;
      PrintFormat("Step %d: delta_y = %.6f, Angle = %.6f degrees", i+1, delta_y, angle);
      delta_y *= 10.0; 
   }
}

// results:
//Step 1: delta_y  = 0.001000,       Angle = 0.000191 degrees
//Step 2: delta_y  = 0.010000,       Angle = 0.001910 degrees
//Step 3: delta_y  = 0.100000,       Angle = 0.019099 degrees
//Step 4: delta_y  = 1.000000,       Angle = 0.190985 degrees
//Step 5: delta_y  = 10.000000,      Angle = 1.909152 degrees
//Step 6: delta_y  = 100.000000,     Angle = 18.434949 degrees
//Step 7: delta_y  = 1000.000000,    Angle = 73.300756 degrees
//Step 8: delta_y  = 10000.000000,   Angle = 88.281642 degrees
//Step 9: delta_y  = 100000.000000,  Angle = 89.828113 degrees
//Step 10: delta_y = 1000000.000000, Angle = 89.982811 degrees
    

As you can see, the output is highly unstable. To obtain a normalized and comparable result, we need to scale delta Y for each instrument separately, taking into account both the number size and the number of decimal places. 

Surely we do not scale delta X, as datetime is a stable reference which you can always be sure of unless we are talking about a year before 1970. To scale, you need to calculate a factor and then amplify or reduce our delta Y as needed. It is important to note here that the factor must be calculated based for the instrument, not its delta! So using formula: angle = MathArctan((delta_y * dynamic_scaling_factor) / delta_x) * 180.0 / M_PI;  is correct way to calculate angles and the required scaling is not particularly difficult but I don't want to emphasize that at all. To analyze statistics, we need normalized values ​​that can always be compared to each other. This means that they have to be degrees 0 to 90 and 0 to -90, but instead can be used any comparable scales. That's why there are easier ways... let's look this. 

        void angle_progression2() 
{
   double y1 = 0.004; 
   double y2 = 0.003;
   int delta_x = 300; // constant time 5 minute

   for (int i = 0; i < 10; i++)
   {
      double delta_y = ((y1 - y2) / y1 * 100.0); 
      double ratio   = delta_y / delta_x;
      double angle   = MathArctan(ratio) * 180.0 / M_PI;

      PrintFormat("Step %d: y1 = %.5f, y2 = %.5f, delta_y = %.5f %, Y/X Ratio  = %.5f %, Angle = %.5f degrees",i+1, y1, y2, delta_y, ratio, angle);
      y1 *= 10.0;
      y2 *= 10.0; 
   }
} 

Step 1: y1 = 0.00400,        y2 = 0.00300,       delta_y = 25.00000  , Y/X Ratio  = 0.08333  , Angle = 4.76364 degrees 
Step 2: y1 = 0.04000,        y2 = 0.03000,       delta_y = 25.00000  , Y/X Ratio  = 0.08333  , Angle = 4.76364 degrees
Step 3: y1 = 0.40000,        y2 = 0.30000,       delta_y = 25.00000  , Y/X Ratio  = 0.08333  , Angle = 4.76364 degrees
Step 4: y1 = 4.00000,        y2 = 3.00000,       delta_y = 25.00000  , Y/X Ratio  = 0.08333  , Angle = 4.76364 degrees
Step 5: y1 = 40.00000,       y2 = 30.00000,      delta_y = 25.00000  , Y/X Ratio  = 0.08333  , Angle = 4.76364 degrees
Step 6: y1 = 400.00000,      y2 = 300.00000,     delta_y = 25.00000  , Y/X Ratio  = 0.08333  , Angle = 4.76364 degrees
Step 7: y1 = 4000.00000,     y2 = 3000.00000,    delta_y = 25.00000  , Y/X Ratio  = 0.08333  , Angle = 4.76364 degrees
Step 8: y1 = 40000.00000,    y2 = 30000.00000,   delta_y = 25.00000  , Y/X Ratio  = 0.08333  , Angle = 4.76364 degrees
Step 9: y1 = 400000.00000,   y2 = 300000.00000,  delta_y = 25.00000  , Y/X Ratio  = 0.08333  , Angle = 4.76364 degrees
Step 10: y1 = 4000000.00000, y2 = 3000000.00000, delta_y = 25.00000  , Y/X Ratio  = 0.08333  , Angle = 4.76364 degrees   

In this case, the Y delta represents percentage of price movement, making it applicable to any instrument regardless of price scale. This approach effectively normalizes price differences, providing a stable and comparable output for the y/x ratio. Percentages and percentiles offer a reliable output since they always fall within a range of 0 to 100. This makes calculations straightforward, as they simply incorporate the x-dimension into the percentage calculation, nothing more. We can further normalize this to a 0-to-1 scale, allowing for additional transformations as needed. As I mentioned at the beginning, we don't actually need angle of MathArctan to analyze the x and y ratio. However, this is basic normalization and not the main focus of this discussion. For example, we can use the y/x ratio to identify consolidation periods or high volatility. This approach has advantages, but similar insights can also be obtained by analyzing x and y separately.

Now, let's consider a more advanced approach, what if we don't evaluate the output purely linearly but instead introduce an additional weighting factor? For instance, if the angle is very steep but short-lived, we assign it a lower score and if the steep angle persists over time, it accumulates more weight. Conversely, if time stretches significantly while the angle remains consistent, it could be evaluated differently. This opens up endless possibilities for enhancing the y/x ratio with additional value-based assessments, allowing for more refined analysis beyond simple linear relationship. The y/x ratio enhances the analysis of data distribution, making it easier to identify patterns and distinguish different behaviors in various situations. To unlock deeper insights, we can apply more advanced techniques such as polynomial regression, exponential or logarithmic scaling, and other non-linear transformations. These methods should not be overlooked because analyzing the y/x ratio we can reveal hidden correlations, divergences, or anomalies that may not be immediately apparent when examining the y and x axes separately.

This is  why this topic is so intriguing, and I hope we can explore it further in more depth.