CopyTicksRange () does not work correctly in MQL5. a - page 5
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
Yes, I read the function descriptions all the way through, and if in doubt, I'll rummage around the forums too. Everyone's notion of fast is different. Dynamics is slower by definition, because there is constant redistribution of memory. The second disadvantage is fragmentation - sometimes you make a mistake with the dynamics and then the memory is not enough to close the terminal :)))
Ping has nothing to do with it, after the first download, the ticks are given already from the base, in theory, of course :) I was taught that the program should be accelerated by optimization, but not by the hardware base - this is automatic. And what difference does it make, what is the connection - today it is one, tomorrow another - it doesn't depend on the algorithm.
I have my own broker, that's why I've been working with them for more than a year. My task is now to master mathematics on ticks, but not trading or freelancing.
Again, for the visually impaired:
From the reference
Функция CopyTicksRange() предназначена для запроса тиков из строго указанного диапазона, например, за конкретный день истории.From
The CopyTicksRange()function is intended to request ticks from a strictly specified range, for example, for a particular day of the history.
The CopyTicksRange() function doesn't get the ticks from the strictly specified range "2021.01.29 23:57:00:000, 2021.01.31 23:59:00:000". Returns ticks from a completely different range.
Please provide measurements for this claim. I give a big role to performance issues in combat advisors.
Here is a sample code. I wrote in a hurry, there may be blunders. Measurements for the following options:
1) the ugliest, when the array expands as needed
2) slightly optimized - when expanded to the intended portion
3) a little more optimized - expands with a margin of several servings
4) static memory, which will obviously always be zero
It is clear that if you dynamically allocate a huge amount of memory for everything in the world, then the speed will be like on statics, but this rarely happens
On dynamically expanding arrays, the worst thing is memory fragmentation, which will gobble up all of it in the process. Well, the ever-growing time for the next expansion - because. in highly fragmented memory, it takes longer to search for a suitable piece
results in microseconds. The sharp increase in the required time in the first column towards the end is most likely due to the fact that the terminal probably allocates memory for arrays in small blocks, optimizes a little for us. But when the array becomes larger than the block, it starts stupidly looking for the first suitable empty piece. I twisted much further, it becomes very long there ... several seconds. And there were only about 1,000,000 cells
Here is a sample code. I wrote in a hurry, there may be blunders. Measurements for the following options:
1) the ugliest, when the array expands as needed
2) slightly optimized - when expanded to the intended portion
3) a little more optimized - expands with a margin of several servings
4) static memory, which will obviously always be zero
It is clear that if you dynamically allocate a huge amount of memory for everything in the world, then the speed will be like on statics, but this rarely happens
On dynamically expanding arrays, the worst thing is memory fragmentation, which will gobble up all of it in the process. Well, the ever-growing time for the next expansion - because. in highly fragmented memory, it takes longer to search for a suitable piece
results in microseconds. The sharp increase in the required time in the first column towards the end is most likely due to the fact that the terminal probably allocates memory for arrays in small blocks, optimizes a little for us. But when the array becomes larger than the block, it starts stupidly looking for the first suitable empty piece. I twisted much further, it becomes very long there ... several seconds. And there were only about 1,000,000 cells
And that's how I get it
Truth corrected a little
And if you initialize arrays
then so
it's been tested for two years!
What a stubborn one! Read what they wrote above - CopyTicks glitches just the same. If you like looking for ways to make a buggy function work or find buggy workarounds, then don't bother - it's not about that
In two years you could have understood that if a function doesn't work the way you want it to work and the developers know about it and don't fix it, it's not called a bug...
Thumbs up, cool educated programmers.........
INT_MAX = 2147483647
in fact, you have immediately snatched away an INT_MAX* sizeof(double) piece of memory and then work as with static
you might have written
double d[INT_MAX]; - it will be the same for you as
the only difference will be in operation of the ArraySize() function while the whole amount of memory will be shat off at once
Fixed it, will be in beta today.
Thank you very much. I'm going to pump for joy :) the workaround was very resource-intensive
Fixed it, will be in beta today.