Discussing the article: "Role of random number generator quality in the efficiency of optimization algorithms" - page 7

 
The algorithms will be located at this address. And I will publish them in the codebase.
GitHub - JQSakaJoo/Population-optimization-algorithms-MQL5: Population optimization algorithms
GitHub - JQSakaJoo/Population-optimization-algorithms-MQL5: Population optimization algorithms
  • JQSakaJoo
  • github.com
Population optimization algorithms. Contribute to JQSakaJoo/Population-optimization-algorithms-MQL5 development by creating an account on GitHub.
 
fxsaber #:

Hold on. Now Andrew's algorithms are responsible for exactly the type of optimisation that MT5-Tester does. In the quoted one you are talking about the overhang over the optimisation algorithm.

In the discussion you can still feel some kind of optimisation algorithm, which is not formally a competitor of the algorithm in MT5-Tester, but solves quite different search tasks. There were no such algorithms in Andrei's series of articles.

Exactly so - an "overlay", an additional (very important) toolkit, which, IMHO, Andrei would have no trouble adding. I wrote at the very beginning that I didn't notice it in the articles, although it would have been useful. Now, for some reason, a political decision has been made to limit it to refined "optimisation algorithms", and not to touch the finished solution of "optimisation" in a more practical sense. It's like designing a car to set a speed record in the Mojave Desert, but most people won't use it, because you have to drive on rough terrain and mountain serpentines. ;-)

PS. This toolkit is also missing in the standard optimiser. There is a forward test for a tick, but it does not help much.

 

Forum on trading, automated trading systems and testing trading strategies

Discussion of the article "The role of random number generator quality in the efficiency of optimisation algorithms"

fxsaber, 2024.03.30 18:16

Suggested an iterative approach, when before each iteration as another run of the GA, the areas of the found vertex (on the previous iteration) are poked out.

Even such a head-on approach would work for me. But I don't understand how to determine the area of poking in a multidimensional space?

Any thoughts, how to determine the area of the found global peak by the calculated values (let them be 10 000 pieces) of FF? To force -DBL_MAX in this area on the next iteration of FF.

 
fxsaber #:

Even such a frontal option would work for me. But I don't understand how to define the area of poking in a multidimensional space?

Any thoughts, how to determine the area of the found global peak by the calculated values (let them be 10 000 pieces) of FF? To force -DBL_MAX in this area on the next iteration of FF.

You can take several nearest points with the maximum value and calculate the coordinates of their "centre of mass". It is necessary to determine beforehand what minimum distance is allowed between the points.
 
Andrey Dik #:
You can take several nearest points with the maximum value and calculate the coordinates of their "centre of mass". It is necessary to determine the minimum distance between the points.

I don't understand how to calculate the distance between points. Each coordinate has its own parrots.

I thought to take a certain part of the optimisation range of this coordinate as a parrot of a coordinate.


For example, optim X4 from -5 to +5, the parrot is equal to 1% (conditionally) of the interval length (10).

 
Stanislav Korotky #:

Exactly so - a "canopy", an additional (very important) toolkit, which, IMHO, Andrei would have no problem adding. I wrote at the very beginning that I didn't notice it in the articles, although it would have been useful. Now, for some reason, a political decision has been made to limit it to refined "optimisation algorithms", and not to touch the finished solution of "optimisation" in a more practical sense. It's like designing a car to set a speed record in the Mojave Desert, but most people won't use it, because you have to drive on rough terrain and mountain serpentines. ;-)

PS. This toolkit is also missing in the standard optimiser. There is a forward test for a tick, but it does not help much.

I wanted to describe the terminology, but now I don't even know if there is a need for it....

No, parsing optimisation algorithms and studying them thoroughly is not akin to building a car, but to understanding the subtleties of the principles of an internal combustion engine. And these principles can be used to build tractors and bolides.

 
fxsaber #:

I can't figure out how to calculate the distance between points. Each coordinate has its own parrots.

I thought to take a certain part of the optimisation range of this coordinate as a parrot of a coordinate.


For example, optim X4 from -5 to +5, the parrot is equal to 1% (conditionally) of the interval length (10).


take a relative range, for example - 1;1
bring the ranges of parameters into this range.
calculate the "centre of mass"
bring the coordinates of the centre of mass into the original parameter ranges.
 
Andrey Dik #:

adopt a relative range, e.g. - 1;1
bring the parameter ranges into this range.
calculate the "centre of mass"
bring the coordinates of the centre of mass into the original parameter ranges.

I wouldn't take the centre of mass. Just the coordinate of the best point.

 
Took a feature like this.
input double X = 0;

double OnTester() { return(MathTan(X)); }

Some incomprehensible result. If you implement iterative poking, I suppose you can find a lot of "rocks".

Tangent is an unsuccessful FF, TS-FF is much easier to poke out.

 
fxsaber #:

I wouldn't take the centre of mass. Just the coordinate of the best point.

And I understood that by locals to predict global... but in general, it is necessary to bring the ranges of parameters to one scale, outside the AO, that then to carry out some manipulations with them. Well, or at once, that the AO would work in space with coordinates in a single system of measurement.