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
In essence, all algorithms are the same. Everyone modifies the array element by element, and everyone strives for Fedoseev's variant, because it does not have anything unnecessary.
Only in my case, it is done in blocks using ArrayCopy, so there is a speed advantage.
And what about Pyotr? Has everyone "torn up"? Nobody put his code in the checker. I wonder how, and to what extent, he blew everyone away on the board.
I thought about the reasons and corrected two lines in it to remove one third of elements, not 0.1%.
Conclusion: calculating addresses in an array with an arbitrary distance between their numbers is still worse than processing items in a row at a given step, all the more so at step 1, the compiler can optimize it.
Oh, I see what you mean. Somehow I missed this phrase
Yes, of course it's clear, but still, even when I have to throw out every third element (then ArrayCopy stops working for me and winnings disappear) the picture is different:
Pavlov's variant really doesn't work, but you also have correct and incorrect checksum.
And what about Peter? Did you tear them all apart? No one inserted his code into the checker. It's interesting how and to what extent he's blown everyone away on the board.
I still don't understand his flight of fancy. He still hasn't provided a ready-made function. And if I complete it for him, he'll accuse me again of re-doing everything. ))
I still don't understand his flight of fancy. He still hasn't provided a ready-made function. And if I complete it for him, he'll accuse me again of re-doing everything. ))
Well, looking at his code from a mobile phone I had an impression that he writes in a "straightforward manner". That's why he didn't provide the function - he does everything in a row. And his script is not a function but straightforward code. Of course, such a script may not imply a function, but... I think he lacks goto for his flights :)
But that's just my feeling.
Fixed Pavlov's variant.
Your values are strange. Maybe you have run the script after profiling or debugging without recompiling the code?
That's how it works for me:
And in your variant it gives wrong checksum. Creation of an additional array is not profitable at all, on the contrary, it slows down the process and eats up additional resources.
Corrected.
I've run it a few times, the results are dangling - computer's really busy, won't be free until Saturday. Better check with someone else. But the checksum now matches. For highly sparse unnecessary values (0.1%)
2018.11.13 21:35:16.888 del_2 (GBPUSD.m,H1) option Pastushak: Checksum = 497057781; elements - 998984; execution time = 418662 microseconds
2018.11.13 21:35:16.898 del_2 (GBPUSD.m,H1) variant Korotky: Checksum = 497057781; elements - 998984; execution time = 10683 microseconds
2018.11.13 21:35:16.918 del_2 (GBPUSD.m,H1) variant Fedoseev: Checksum = 497057781; elements - 998984; execution time = 9740 microseconds
2018.11.13 21:35:16.928 del_2 (GBPUSD.m,H1) variant Semko: Checksum = 497057781; elements - 998984; execution time = 4691 microseconds
2018.11.13 21:35:16.944 del_2 (GBPUSD.m,H1) variant Pavlov: Checksum = 497057781; elements - 998984; execution time = 12512 microseconds
2018.11.13 21:35:16.957 del_2 (GBPUSD.m,H1) variant Nikitin: Checksum = 497057781; elements - 998984; execution time = 10720 microseconds
2018.11.13 21:35:16.978 del_2 (GBPUSD.m,H1) variant Vladimir: Checksum = 497057781; elements - 998984; execution time = 17197 microseconds
for one third
2018.11.13 21:57:17.838 del_2 (GBPUSD.m,H1) variant Pastushak: Checksum = 668222; elements - 667065; execution time = 65732 microseconds
2018.11.13 21:57:17.838 del_2 (GBPUSD.m,H1) variant Korotky: Checksum = 668222; elements - 667065; execution time = 4757 microseconds
2018.11.13 21:57:17.848 del_2 (GBPUSD.m,H1) variant Fedoseev: Checksum = 668222; elements - 667065; execution time = 4815 microseconds
2018.11.13 21:57:17.858 del_2 (GBPUSD.m,H1) variant Semko: Checksum = 668222; elements - 667065; execution time = 5812 microseconds
2018.11.13 21:57:17.858 del_2 (GBPUSD.m,H1) variant Pavlov: Checksum = 1001157; elements - 667065; execution time = 0 microseconds
2018.11.13 21:57:17.858 del_2 (GBPUSD.m,H1) variant Nikitin: Checksum = 668222; elements - 667065; execution time = 4749 microseconds
2018.11.13 21:57:17.868 del_2 (GBPUSD.m,H1) variant Vladimir: Checksum = 668222; elements - 667065; execution time = 9814 microseconds
Pavlov has crashed again.
My conclusion about speeding up loop for loops is probably incorrect for MQL languages.
And creating an additional array should reduce the duration of the transaction itself by removing the superfluous ones, keeping the array unchanged until the necessary moment of its start. So far, there's been no talk of data integrity here.
What about Peter? Did he "tear up" everyone? Nobody put his code in the checker. I wonder how, and to what extent, he blew everyone away on the board.
But I've managed to get a hold of Peter's version.
It's quite compact and even works correctly. Kudos to Pyotr.
But in terms of speed he ranks second from the end. Or first place from the end if you don't count the original, completely unsuitable for speed version of the owner of this thread.
:-) if you don't try to keep the order, the time is O(1) , the total number of steps of all the loops= array size
too lazy to code :-)
1. Search for first 3 from left to right.
2. if found, then look for a non-three from right to left, copy it to the place of the 3.
continue until 1,2 have intersected, trim the array by the number of copies.
ideally, it is exactly 1/2 of"bubble sorting" :-) if, instead of copying, you make a swap, the output will be a partially ordered array (all 3-thirds moved to the right)
More refinement:
Sorry, they say you're a good marketer, but a programmer... even worse than me.
1. The internal integer variable is not initialized, so it will be zero, but not guaranteed. In the loop, the shift backwards will not happen (the first time) for two reasons at once - guess which one.
2. (most importantly) you first shift the array elements, then increase the value of the deleted variable, and then there will be a loop and the next shift will happen one more than necessary. In other words, your code will avalanche the original array.
There are no extra elements in the array:
The array has all unnecessary elements:
Sorry, they say you're a good marketer, but a programmer... even worse than me.
Alexei, you're killing a young talent...
this marketer hasn't been able to start selling for 5 years...and you say he's even worse as a programmer :-)