Slope Calculations: Per 1 minute Bar or every tick ?
I'm wandering about the flesdability of slope calaulations for every tick, but have doubts that would get that sort of respnsoe time from thr brkoer's server especiallyu on a lots fo charts at once or if the ptracticla limitaion of a 1 minute time frame is more reaistick; though I haave doubts on the latenc of this as well?
If calclted per m1 barsn would the scalingb of the chart affect it?
What is it that you wnat to calculate?
The "SLOPE" needs to be defined carefully before you start.
I would define at as follows: Variation in price over a set period of time.
Now I would calculate the price variation (open to close) for the Period involved.
Now to smooth out the spikes in the results that I get I would average the value over a number of candles.
After all that work, why don't you have a look at the ATR ot Average True Range indicator already in the platform.
It is nicely described here: https://www.metatrader5.com/en/terminal/help/indicators/oscillators/atr
why re-invent the wheel?
whocares
I'm wandering about the flesdability of slope calaulations for every tick, but have doubts that would get that sort of respnsoe time from thr brkoer's server especiallyu on a lots fo charts at once or if the ptracticla limitaion of a 1 minute time frame is more reaistick; though I haave doubts on the latenc of this as well?
If calclted per m1 barsn would the scalingb of the chart affect it?
As a second thought, also look at the Price Rate of Change indicator: https://www.mql5.com/en/code/9340
whocares
Hi WC,
The absolute angle tha I wnat to calculate IS price VS time. In someones else topic I posted somethings about this and Phy said that he would calculate the 'slope' as opposed to teh 'Angle' I'm not sure what the distinction is that he was making, and I caqn't fidn the topic again. Thsi goes back to an earlier posting where I was inquiring about finding the 'absolut angle' as well as trying to run adn EA without any charts at all. I don't want the 'average' though. I want the smalest time fram and highest resolution that that I can possibly get woth fair ly decent consistancy adn reliablity taking factors such as latency, lags, dropout etc. Regardless of what time fraim I use, it doess have to be consistent in that teh slope or the absolute angle is NOT altered b a change in time fram caused by time factors such as indicated above.
SPeaking of 'ROT', I have been trying t find a way to utilize and apply calculus to MQL4
THe best of the Season to yo and yours WHoCares
slope = priceChange / timeChange
angle = MathArctan(slope)/ 3.1415965 * 180
Take your pick.
I'm wandering about the flesdability of slope calaulations for every tick, but have doubts that would get that sort of respnsoe time from thr brkoer's server especiallyu on a lots fo charts at once or if the ptracticla limitaion of a 1 minute time frame is more reaistick; though I haave doubts on the latenc of this as well?
If calclted per m1 barsn would the scalingb of the chart affect it?
Try this one if the angles from -90 to 90 degrees is OK with you:
double slope = ((price1-price2)/Point)/(Number_of_Bars_Back);
double Angle = 90 * slope;
Number_of_Bars_Back - distance in bars from price1 to price2
Sample: Calculate angle: From point on EMA and to a moving current point - Close[0]:
int EMA_Period = 20;
double price1 = Close[0];
double price2 = iMA(NULL,0,EMA_Period,0,MODE_EMA,PRICE_CLOSE,Number_of_Bars_Back);
price2 = NormalizeDouble(price2,Digits); - not really required in this sample
double slope = ((price1-price2)/Point)/(Number_of_Bars_Back);
double Angle = 90 * slope;
The angle will not change on windows re-size etc. with this calculation.
ok...
I get 10 pips and 2 bars = slope 5
5*90 = 450
Now what?
Hi Doug
I've been biting my tongue on this one (being an engineer). Listen to Phy. Use slope.
Angle has no meaning on a graph where the axes have different units, in this case price and time. I'm not sure how technical to be, but angles are unit-less quantities and can only be calculated using variables that have the same units. For example, 5 ft forwards then 5 ft left is the same as 7.07 ft at an angle of 45 degrees - makes sense. However, 5 ft forwards then 5 minutes left means what?
In this case, slope has units of price/time (or points/time) and it stays the same regardless of scale of the axes. If you have a line with a of slope 10 points per bar then drag the scale, the visible angle changes but the value of the slope stays the same, i.e. 10 points / bar.
If you want to calculate anything from it, use the slope. An added benefit is that calculus is then not required. ;-)
On your question of the feasibility of calculating it every tick, it's perfectly feasible because the calculation is very simple. However, you would be using the time between ticks, which is in seconds. With ticks coming so quickly this time accuracy would make your slope calculation wildly variable. You would need to take whocares advice and average it or, better, do it over larger time frames, e.g. 1 min or 5 min. It depends on your purpose.
Cheers
Jellybean
The slope or angle over a period of several basrs is to coarse. Even wtih a time period of m1 I need a higher resolution than that IF REALISTICALLY possible. Remember I want to utilize as many charts simultaneously as is possible while still remaining accuracy: 18 ~24 if I can.
I understand and know how to calculate the slope or use trig to calculate the angle, the question really is the consistency of the resultant answer being correct and not being affected by either chart scaling nor lags, missed ticks etc. How can I tel when ticks are being missed and compensate for it?. If I have 60 ticks in a 1 minute bar/candlestick or even a line graph (the latter being preferable), and say for example 8 ticks were missed due to whatever reason, then I need to know what the actual number of ticks and there time period was INCLUDING the missed and unreported ones so that it does not affect the slope or angle and give an incorrect answer.
Which brings rise to the question of 'how long of a time period is a 'tick''? Is it an (ideally) fixed time period? If so, what is that time period? Do they vary with the chosen time interval? Do they vary dynamically etc? If so, how do I find out what the actual time period is? I need to know this, but once I do, I STILL need to know what the accurate time period being reported actually is regardless of included errors so that my calculated angle or slope being reported is always true, accurate and reliable otherwise it is basically meaningless. All this being said, perhaps the best approach to this is to request/monitor the server time is and utilize the time interval between the 1st such reported time & price and use the difference in time regardless of what it is and the difference in price and completely leave the issue of 'ticks' out of this entirely.
As WC correctly points out, utilizing 2 absolute reported data sets of server time & the price AT those specific time periods would completely remove the variance due to chart scaling and the # of ticks, regardless of their accuracy or the lack thereof. I don't care about the chart at all & if I could do it, would not even use them. I want to keep the computer overhead to the absolute minimum so will likely just have an otherwise empty chart except for a line graph and use a time period of 1 day or week to minimize this overhead. This way I can just use the reported data sets of sever time & the price at those 2 different times and completely ignore the chart altogether.
Hi Doug
Ticks come when the bid or ask prices change and can be at any time. Sometimes they are many seconds apart (even on the majors) and sometimes they are milli-seconds apart. Their timing is unpredictable because it is largely the market that causes it.
Regarding consistency of the calculation:
The biggest factor in all of this will be the accuracy of the time stamp. The time is reported in whole numbers of seconds, so if one tick comes in a fraction past the second and the next comes in a fraction before the next second, they will both have the same time stamp. The time difference in your slope calculation will be zero (giving a divide by zero error) even though the ticks were nearly a whole second apart. On the other hand if one tick came in a fradtion before the second and the next comes in a fraction after it the time stamp difference will be 1 second, even though they were only a fraction of a second apart.
Whether or not it is meaningful to analyse sequential ticks is another question. I doubt it, in our situation with the latency and dealer/broker set up.
Just for the record, I say again, forget about angle, use slope.
I'm off to bed for some more Christmas summer holiday sleeping. :-)
Cheers
Jellybean
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
I'm wandering about the flesdability of slope calaulations for every tick, but have doubts that would get that sort of respnsoe time from thr brkoer's server especiallyu on a lots fo charts at once or if the ptracticla limitaion of a 1 minute time frame is more reaistick; though I haave doubts on the latenc of this as well?
If calclted per m1 barsn would the scalingb of the chart affect it?