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
290 in total and... on)
Total overkill makes 290.
I take it that there is no pass (real run) but it is fixed (if there are matches)?
Since you have chosen the genetic algorithm, it builds its own crossing plan and population output. The genetic optimiser algorithm is described in the relevant article.
It is unreasonable to run genetics with so few (290) passes. The genetic algorithm should be used with an initial enumeration of at least tens of thousands, preferably millions/billions/trillions, of variants.
MQL5 Reference Manual - Standard Library - Classes for organizing data - CArrayObj (on the website and in the help):
2. The memory management mechanism is disabled.
In this case, CArrayObj is not responsible for memory freeing
Yes, there is no need to test to the most recent existing date.
Choose a reasonable fixed end date in the form of 00:00 of the previous working day, or even the end of the previous working week. If you use the last day all the time, the end of schedule will float periodically, especially if the testing process is long using remote or claud agents.
I used Sunday as the end date. Where else would it make sense? There is no trading on Sunday. What could float there???
Then perhaps the problem is at the other end of the story. What length of history do you need for the indicators to work? At the start of testing it is guaranteed, as I understand it, a hundred preceding bars.
If you need more, you should skip a part of history after the Expert Advisor's start with a length greater than[necessary_number_of_bars - 100]. This solved my problems with correlation of results of tester and optimizer.
Then perhaps the problem is at the other end of the story. What length of history do you need for the indicators to work? At the start of testing it is guaranteed, as I understand it, a hundred preceding bars.
If you need more, skip a piece of history after the Expert Advisor's start with a length greater than[necessary_number_of_bars - 100]. This solved my problems with matching tester and optimizer results.
Thanks, but from the screenshots we can see that the history for Friday (24.06.11) is lost when optimizing through the network
Not a crucial question, but still. String concatenation. The documentation describes two functions StringAdd and StringConcatenate.
The first one says,"The StringAdd() function works faster and more economical in memory than string concatenation by means of addition operations.
The second reads,"The StringConcatenate() function worksfaster and more economical in memory than string binding using addition operations due to the fact that no temporary variables of type string are used.
Result:
2011.06.26 19:10:55 test (EURUSD,H1)№1 2012 milliseconds, i = 10000000
2011.06.26 19:11:04 test (EURUSD,H1)#2 8269 milliseconds, i = 10000000
2011.06.26 19:11:10 test (EURUSD,H1)#3 6661 milliseconds, i = 10000000
It turns out, though, that usual addition is faster.
It turns out, though, that normal addition is quicker.
I used Sunday as the deadline date. Where else is sensible? There's no Torg on Sunday. What could be floating around out there?
As this kind of question needs details, please create a ticket in the Service Desk with additional descriptions - we'll try to sort it out.
The problem, of course, is the history and its synchronicity.
Not a crucial question, but still. String concatenation. The documentation describes two functions StringAdd and StringConcatenate.
The first one says,"The StringAdd() function works faster and more economical in memory than string concatenation by means of addition operations.
The second reads,"The StringConcatenate() function worksfaster and more economical in memory than string binding using addition operations due to the fact that no temporary variables of type string are used.
Result:
2011.06.26 19:10:55 test (EURUSD,H1)№1 2012 milliseconds, i = 10000000
2011.06.26 19:11:04 test (EURUSD,H1)#2 8269 milliseconds, i = 10000000
2011.06.26 19:11:10 test (EURUSD,H1)#3 6661 milliseconds, i = 10000000
It turns out, though, that normal addition is faster.
This seems to be a string concatenation optimization with +.
The compiler is undergoing some serious modifications concerning inclusion of the long expected optimization modes. We will show the results in a while.
It looks like it's the string concatenation optimisation with + that's working.
We are now seriously changing the compiler in terms of enabling the long awaited optimization modes. We'll show you the results in a while.
I see. Well, if it's possible you'll describe it explicitly in the forum (I try to follow all threads).
So far in the algorithm I've left work "+".