Discussion of article "Genetic Algorithms - It's Easy!" - page 16

 
Alexey_74:

Andrew, one more question.

Can we say that such values of these variables are suitable for most optimisation problems?

Yes.

The settings are taken with some "reserve" to increase the searchability (coverage of the search field). For more accurate values (but the probability that a global extremum will be found at all is reduced), you can reduce the mutation parameters and the coefficient of interval boundary shifting.

 
Alexey_74:

Andrew, one more question.

Can we say that such values of these variables are suitable for most optimisation problems? As they say in some sources "... 90% of problems can be solved using a conventional perceptron".

ZAGASTE GA :)

The algorithm is single-threaded, can be easily built into an Expert Advisor, run it in a tester and organise competitions among GAs boo-gah-gah.

 

Wonderful.

Andrei, you know, I am surprised at my impudence, but I have to voice some "criticism" ))

The ServiceFunction() function is called in three places in the UGA code. But this is of no use. Of course, you can see the dynamics on the screen, but it is so fast that you can't see and evaluate it anyway. You can remove its call in the body of UGA(). It is quite enough to call it once after calling UGA().

"... and the violinist is unnecessary, he only consumes extra fuel" (kin dza dza (c))

  ts=GetTickCount();
  UGA( ... );
  ts=GetTickCount()-ts;
  ServiceFunction();
 
Again, it is not crucial. that's why it's a service function, you can use it for debugging, visualisation or something else, or you can not use it at all, who likes it. :)
 

I did an experiment. I made a sum of three sinusoids with "frequencies" 47, 81, 187. I got this

Then I started the search by direct enumeration (3 cycles, 2 nested), though with interruption when the correlation coefficient value = 1.0. Without this condition, all this nonsense would have taken much longer. But this way it was done in 375 seconds (a little more than 6 minutes).

The GA did it in 2 seconds. ))

But there is a question. Here's the result.

Last 2 digits: 2747 - number of FF calls; 506 - number of "states" when correlation coefficient r was equal to 1.0. It turns out that the algorithm could have worked even faster, because r cannot be greater than 1.0 and after the first reaching of r=1 the task is considered completed. But the algorithm reached the state r=1.0 506 times.

These were the parameters

parameters

And this FF.

void FitnessFunction(int chromos)
{
  int cnt = 1;

  while(cnt<=GeneCount)
  {
    F1=Colony[cnt][chromos]; cnt++;
    F2=Colony[cnt][chromos]; cnt++;
    F3=Colony[cnt][chromos]; cnt++;

    Fill(sum);
    r=Pirson(sin,sum,nobs);
    if(r>0.99999999) count++;
  }
  AmountStartsFF++;

  Colony[0][chromos]=r;
}

Question - is there any way to explain to the algorithm that (sometimes) it is possible (necessary) to terminate earlier. Or should we not do it categorically and wait for convergence to be reached?

 

Well, I've been wanting to know the answer to the "how many" question for a long time. This time I took a momentum and put 50 sinusoids on it. The range of values is 1-500. So, if I'm not mistaken, the direct search results in 500^50, i.e. 8.88178419700121252323333890533447266e+134 iterations (if my calculator didn't lie to me). It is clear that it is not possible to convert to seconds (minutes, hours, days, years). Only distant descendants would see the result. The GA did it in 1 hour. 20 minutes. Wow. Additionally, it turned out that the correlation coefficient of the sum of 50 sinusoids with momentum is 0.5275. Why"additionally"? Because I have not had a single opportunity to check this point before. And in some cases, it suggests some thoughts.....

I didn't fixate on sinusoids, it's just that I have it all at my fingertips. Besides, since the goal is to achieve maximum similarity of continuous signals, the result is this very similarity, in other words, the result is unambiguous, besides, easily verifiable.

Andrey, thank you very much for your Product. I would like to read another article of yours in the near future. GA with elite selection. ))

Документация по MQL5: Основы языка / Типы данных / Целые типы / Типы char, short, int и long
Документация по MQL5: Основы языка / Типы данных / Целые типы / Типы char, short, int и long
  • www.mql5.com
Основы языка / Типы данных / Целые типы / Типы char, short, int и long - Документация по MQL5
 
Alexey_74:
...

Question - is there any way to explain to the algorithm that (sometimes) it is possible (sometimes) to terminate earlier. Or it should not be done categorically, and we should wait until convergence is reached?

It is possible. And even necessary. If you know something about the function under study (as in your problem: FF<=1), you should actively use this information to avoid unnecessary calculations and thus reduce the search time.

In this implementation there are no levers to control the algorithm from the outside, but it is enough to add a function to control the forced stop flag.

In the next generation of the algorithm, about which a sequel article is being prepared, there are much more possibilities to control the algorithm from the outside (it generally works on initiation and under control from the outside, and not as it is now - FF is started by the algorithm itself, so there is no possibility to use it in auto-optimising owls without modification).

 
Alexey_74:

....

Andrew, thank you very much again for your Product. I would like to credit another one of your articles in the near future. GA with elite selection. ))

Thanks for the thanks. :)

There will be a sequel, for sure.

And, good luck in finding the optimum! In life, in work, in l... Everything.

 
I'm afraid to ask.... )) Do I understand correctly? The next generation of the algorithm can be formalised as a DLL?
 
yes