What should be added for additional support of universal mathematical calculations in MQL5 and MQL5 Cloud Network? - page 2
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
It's a little bit different. What I wanted to do was to control the course of optimisation.
Roughly speaking do you want your genetics?
Originally, yes, it was asked for genetics.
And I would just use it for auto-optimisation (selecting parameter areas based on previous results).
And I would just use for auto-optimisation (select parameter areas based on previous results).
Roughly speaking you want your genetics?
In this direction, but it's not all so one-sided.
First of all, if the standard GA were satisfied with everything (~10K full parameters, multi-parameter optimization) then most of the dissatisfied would be silenced.
But there's one more drawback, sometimes you want to stop optimization by some kind of instinct, and continue further. Those to make manual corrections to the automatic FF.
If that too, even a small part of demanding users will finally close the issue with GA.
And do not let the developers be embarrassed by a small number of dissatisfied users, they are usually the most advanced ones and it is them that one should look up to.
ZZY But in fact you are right, its genetics closer to the body, and run it in the cludes would be cool. By the way, then it would be possible to solve the issue with valk-forward tests on their own and not have to beg this mode from MQ.
And don't let the developers be embarrassed by the fact that there are few dissatisfied people, usually the most advanced ones.
in fact, this factor is the most important in the rejection process.
In essence, they will have to be distracted by a task that will be used by a narrow circle of advanced people.
In fact, this is the most important factor in refusals.
In essence, they will have to be distracted by a task that will be used by a narrow circle of advanced users.
That's the thing, an advanced user sees more than a novice, over time their vision of the problems will spread to others and they will also want to use the functionality that the advanced user already wants to use.
If you focus on the mainstream, the platform will always be sort of in the past.
Prior to Kodak created a soapbox and a network of developer machines, tourists had no desire to take pictures themselves, it was the prerogative of advanced users and photography professionals (of which there were many at any tourist attraction).
But an innovator came along and created a new service, thereby turning the industry upside down and promoting it to the masses.
That's the funny thing, an advanced user sees more than a novice, over time their vision of the problems will spread to others and they too will want to use the functionality that an advanced user already wants to use.
If you focus on the mainstream, the platform will always be sort of in the past.
The main thing is that before Kodak created the soapbox and its network of developer machines, the tourists had no desire to take their own photos - it was the prerogative of advanced users and photography professionals (of which there were many at any tourist attraction).
But an innovator came along and created a new service, thereby turning the industry upside down and promoting it to the masses.
I agree. With both. :)))
The interface must be thought of. What is custom genetics? If the interface with the claude to do at the level of "SetPopullationForCalc(); GetPopulationFitnessFuncs();" then a flexible and powerful scheme will not work.It would be better to implement exchange with claud on the level of random volume task packages where the population size is not fixed and is passed as a parameter together with the parameter array. In addition, we need to completely detach (at last!!) "optimization" and "testing", with giving (in parallel arbitrary!) possibilities of alternating and combining requests for (1) mass lightweight crowd computing (analog of optimization) of arrays of parameter sets with (2) detailed single runs (analog of "testing"). Then, the bulk forwards are built without problems, and all the rest caca with tea which even now does not come to mind.
Such are the thoughts.
The conclusion is as follows: think of a flexible api layer between the tester and the programs in the terminal. This will solve the ancient problem of "starting genetic optimization in the course of trading with on-the-fly correction of robot parameters" together with other problems unobtrusively.In particular, the Cloud will become a super-universal mass-market mega-computer, capable of solving arbitrary tasks with large volumes of single-type calculations.
For good auto-optimisation, the tester has to be thrown out of the chain.
I'm not talking about auto-optimisationof the EA at runtime, but, for example, wolf-forward on your own.
Selecting parameter ranges for future runs would solve this problem 100% (dates can be limited programmatically using the same parameters).
But this, given the use of cludes, is not as straightforward and unambiguous as it seems.
I'm not talking about auto-optimisingthe EA while it's running, but, for example, wolf-forwarding it in-house.
Um, it's the same from my point of view :)
Firstly, if standard GA were satisfied in everything (~10K full parameters, multi-parameter optimization) then most of the dissatisfied would be silenced.
Yes, most of the 5-10 dissatisfied :)