From theory to practice - page 394
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Thank you:
Yury Kirillov
bas
Aleksey Nikolayev.
Each such intelligent answer uncontrollably brings us closer to the coveted Grail.
I'll read the forum for the last week and tell you about speed of increments. Remember that topic? Yes, that is what I am going to talk about.
Downloading gigabytes of ticks and processing the files to find the speed per second is somehow difficult and time consuming.
MT5 now allows you to work with ticks in the Expert Advisor or script itself. Here is the script for MT5.
In parameters choose date, and adjust number of working days per year for your year.
The number of seconds is (<date of last tick> - <date of first tick>)*(<number of working days in year> / 365).
But this might give errors if not an integer number of weeks were chosen.
The results are written in the log, you can view them in the "Experts" tab of the MT5 terminal.
The first time you run the script, the terminal will most likely start downloading ticks, but the code will not wait until the end of downloading. If dates in log do not coincide with selected dates, wait a minute while terminal finishes downloading ticks and run script again.
I have this (mt5 server MetaQuotes-Demo):
gbpusd 2015: 0.0000184610 per secondeurusd 2015: 0.0000185810 per second
eurusd 2016: 0.0000141310 per second
eurusd 2017: 0.0000122910 per second
eurusd 2018: 0.0000147410 per second
gbpusd 2016: 0.0000208510 per second
gbpusd 2017: 0.0000155810 per second
gbpusd 2018: 0.0000178510 per second
I assume that the results will be different for each broker. Whoever creates ticks more often will have more price passes.
I recall Doc's answer to the question, will the average tick increment rates, for example over a year, be the same?
The answer was not obvious and disgusted me - NO. The average speeds do NOT coincide. Hooray! In front of my eyes the hard road to the Grail had turned into sand...
I had to stop bidding for a week, because without knowing which average speed should be used, over what period of time - all further calculations become meaningless.
Now, as I process the data, I will show the results.
Hence, the standard deviation of the price from the mean in the sliding window = 4 hours takes the form:
sigma = Root((SUM(ABS(return))/T)*(SUM(ABS(return))/N)*14400)
where T is the running time of the system (--> to infinity).
Recall the formula for calculating the standard deviation.
T is the running time of the system. But the formulation--> to infinity has to be discarded.
But at what period of time then should the average speedSUMM(ABS(return))/T be considered?
Asaulenko's answer: "It makes no difference for me at all. NS counts all by itself, because I feed it correctly and help myself".
Answer by certain Andrei: "I should get rid of white noise in the fastest way, extract a healing signal and count ACF relentlessly".
Helpers...
It's high time they played dominoes.
The most logical answer is to calculate the average speed in the time sliding window in which you work.
Yes?
Let's check.
The formula of the standard deviation, in this case, takes a form known to advanced traders:
sigma = (AMOUNT(ABS(return))/ Root(N).
Let's look at quantile =3.5 (What is this quantile?!?! Just chose it that way) for the EURUSD pair of two weeks ago:
Average weekly increment rate =1.07850444326147 pips/s
For the EURUSD pair last week:
Average Rate of Increment for the week =0.77692550158958 pips/s
So what do we see?
Yeah, nothing. The usual crap - Bollinger Bands and nothing more.
More important is the fact that the average weekly increment rates differ from each other. And by a lot.
Knowing that average rates at T --> to infinity and T = sliding time window size do not suit us, we are left with the latter option:
The standard deviation of price from the mean in the sliding time window = 4 hours is calculated using the formula:
sigma = Root((SUM(ABS(return))/T)*(SUM(ABS(return))/N)*14400)
whereT is the current system running time from the beginning of the trading week.
We look at the same quantile =3.5.
Much better.
This is how you should work with channels!
Thank you for your attention.
More important is the fact that the average weekly incremental rates differ from each other. And by a lot.
And with a certain method of calculating rate, it is almost the same (sometimes there is a difference of tenths of decimal places, but mainly by thousandths or more). And the rate over time N is the same (or almost the same) for different currency pairs. Interesting.
Alexander_K2:
The standard deviation formula, in this case, takes the form known to advanced traders:
sigma = (SUM(ABS(return))/ Root(N).
Let's look at quantile =3.5 (What is this quantile?!?! Just chose it that way) for the EURUSD pair of two weeks ago:
Where did you get this curve formula? This sigma goes to infinity as N increases for a 4-digit quotation when almost all ABS(return) are the same and equal to 0.0001. If from the square root law I exploit https://www.mql5.com/ru/forum/221552/page19#comment_6168925, there is no summation there, one set of OHLC is taken.
Gentlemen!!!
I would like to turn to you, once again, for help, waiting in vain.
...
What should be done to make the distribution from bimodal to unimodal and the process Poisson? Don't ask why and what for.
Increase the size of the sliding window, say, to 24 hours? Wouldn't the same picture be observed?
You know the answer long ago, all you have to do is "tweak" the data itself and you will have unimodality. For example, by inserting non-existent zeros in the right places. The main thing, according to your working methodology, is not to worry about "why".
Where did you get this curve formula? Such a sigma goes to infinity as N increases for a 4-digit quotation when almost all ABS(return) are the same and equal to 0.0001. If from the square root law I exploit https://www.mql5.com/ru/forum/221552/page19#comment_6168925, there is no summation there, one set of OHLC is taken.
Why does it go to infinity?