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
A simple example. The optimization algorithm hangs on a chart somewhere. The Expert Advisor is optimized in the built-in tester by a full search. So you can use your own optimization algorithm instead of the regular one.
Another example. The Expert Advisor works in the chart and trades. It saves the trade results after some time to the algorithm (can be inside or outside of the Expert Advisor) together with its parameters and receives new parameters back and then continues trading (in your case we would need to run a historical run, while in my case we can use a "live" optimization).
And so on. That is, in these examples the algorithm is completely independent of the task.
I deliberately applied these examples to trading. We are traders.
Something out of the ordinary.
The Expert Advisor has already been optimized in the tester, so what does this have to do with your own optimization algorithm?
The second case is a bit clearer. Yes, if you provide single independent calls, you can call it one by one. And you can do it all at once by a separate process. I see, but it is a complication of the algorithm and we are moving away from the purpose of the Championship. The purpose of the Championship is the optimization algorithm, not its application. There are a lot of people who do not understand it, and now it is getting even more complicated.
in general, like this, and of course there will be a time-keeping counter. outline:
1. Something out of the ordinary. Optimization of the Expert Advisor has already been run in the tester, and what does it have to do with its own optimization algorithm?
2. The second case is a bit clearer. Yes, if you provide single independent calls, you can call them one by one. And you can do it all at once by a separate process. I see, but this is a complication of the algorithm and a departure from the purpose of the Championship. The purpose of the Championship is the optimization algorithm, not its application. There are a lot of people who have not understood it, and now it is getting more complicated.
1. Nothing out of the ordinary, it's just a real life situation. An in-house tester makes one run after another (one parameter - counter is taken over) and we control optimization of all parameters and in unlimited quantity.
2. We decided to use 2 variants of work with FF. So everything is fine, there is no problem, whoever wants, so will use optimization.
Participants are free to choose which test script to work with, the first or the second.
In this code, it's not a one-time call, but the main part of the algorithm is moved outside, with some part of the algorithm being imposed on the participant. According to the initial conditions, the participant has the right to hide the whole algorithm.
Where is the imposition there? Ask the algorithm how many times and what to count, the participant's algorithm decides such things. Algorithms can be very different in architecture from the same GA, and the example allows to use an algo on any working principle.
I showed service functions there - they can be empty if not needed by the participant.
Where is the imposition there? Ask the algorithm how many times and what to count, the participant's algorithm decides such things. Algorithms can be very different in architecture from the same GA, and the example allows to use an algo on any working principle.
I showed service functions there - they may be empty if not needed by the participant.
Also, pass in the participant function the allowed number of FF calls, so that we can distribute the number of epochs and the number of individuals.
For example, the algorithm is told that you can have a maximum of 100 FF calls... Aha! - he (the algorithm) thought, I'll cheat everyone and call outthe music for 50 notes, I'll call the FF only 50 times. :)
No, let him count as many as he needs. And we will decide when to stop it. After all, the number of FF calls will be evaluated as an indicator of quality of work.
For example, the algorithm is told that you can have a maximum of 100 FF calls... Aha! - he (the algorithm) thought, I'll cheat everyone and call outthe music for 50 notes, I'll call the FF only 50 times. :)
No, let him count as many as he needs. And we will decide when to stop it. After all, the number of times the FF is called will be judged as a measure of performance.
What is the point of slyly calling it less times? You can do less, you can't do more. What is the problem?
The FF function counts the calls. If more than is allowed, disqualification.
This is roughly the template of a member's library:
What's the point of being so cunning and calling fewer times? You can do less, you can't do more. What's the problem?
The ff function counts the calls. If more is allowed, disqualification.
Fewer ff runs is better, that's the point. This can be a bit tricky.
No need to limit the algorithm, let it count. Either it will decide to stop on its own, or it will be forcibly stopped. The algorithm doesn't need to know how many runs is the ceiling - no one will know the ceiling. There will be no disqualifications. The algorithm will solve the problem as it was able to do.
The only disqualification is an attempt to save the results and use them in subsequent runs of the check script.