Discussione sull’articolo "Algoritmi Genetici - È Facile!" - pagina 16

[Andrey Dik]

Alexey_74:

Andrew, un'altra domanda.

Possiamo dire che tali valori di queste variabili sono adatti alla maggior parte dei problemi di ottimizzazione?

Si.

Le impostazioni sono prese con una certa "riserva" per aumentare la ricercabilità (copertura del campo di ricerca). Per ottenere valori più precisi (ma la probabilità di trovare un estremo globale è ridotta), è possibile ridurre i parametri di mutazione e il coefficiente di spostamento dei confini dell'intervallo.

[Mykola Demko]

Alexey_74:

Andrew, un'altra domanda.

Possiamo dire che tali valori di queste variabili sono adatti alla maggior parte dei problemi di ottimizzazione? Come si dice in alcune fonti "... il 90% dei problemi può essere risolto utilizzando un perceptron convenzionale".

ZAGASTE GA :)

L'algoritmo è a thread singolo, può essere facilmente integrato in un Expert Advisor, eseguito in un tester e organizzato gare tra GA boo-gah-gah.

[Aleksei Morozov]

Meraviglioso.

Andrei, sai, sono sorpreso della mia impudenza, ma devo esprimere qualche "critica" ))

La funzione ServiceFunction() viene chiamata in tre punti del codice UGA. Ma questo non serve a nulla. Certo, si può vedere la dinamica sullo schermo, ma è così veloce che non si può vedere e valutare comunque. È possibile rimuovere la sua chiamata nel corpo di UGA(). È sufficiente chiamarlo una volta dopo aver chiamato UGA().

"... e il violinista non è necessario, consuma solo carburante extra" (kin dza dza (c))

  ts=GetTickCount();
  UGA( ... );
  ts=GetTickCount()-ts;
  ServiceFunction();

[Andrey Dik]

Ancora una volta, non è cruciale. è per questo che è una funzione di servizio, si può usare per il debug, la visualizzazione o qualcos'altro, o si può non usarla affatto, a chi piace. :)

[Aleksei Morozov]

Ho fatto un esperimento. Ho fatto una somma di tre sinusoidi con le "frequenze" 47, 81 e 187. Ho ottenuto questo

Poi ho iniziato la ricerca per enumerazione diretta (3 cicli, 2 annidati), anche se con interruzione quando il valore del coefficiente di correlazione = 1.0. Senza questa condizione, tutta questa assurdità avrebbe richiesto molto più tempo. Ma in questo modo è stato fatto in 375 secondi (poco più di 6 minuti).

Il GA lo ha fatto in 2 secondi. ))

Ma c'è una domanda. Ecco il risultato.

Ultime due cifre: 2747 - numero di chiamate a FF; 506 - numero di "stati" quando il coefficiente di correlazione r era uguale a 1,0. Si scopre che l'algoritmo avrebbe potuto lavorare ancora più velocemente, perché r non può essere maggiore di 1,0 e dopo il primo raggiungimento di r=1 il compito è considerato completato. Ma l'algoritmo ha raggiunto lo stato r=1,0 506 volte.

Questi erano i parametri

E questo 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;
}

Domanda: c'è un modo per spiegare all'algoritmo che (a volte) è possibile (necessario) terminare prima. Oppure non dovremmo farlo categoricamente e aspettare che venga raggiunta la convergenza?

[Aleksei Morozov]

È da molto tempo che desidero conoscere la risposta alla domanda "quanti". Questa volta ho preso un momento e ci ho messo sopra 50 sinusoidi. L'intervallo di valori è 1-500. Quindi, se non sbaglio, la ricerca diretta porta a 500^50, cioè 8,88178419700121252323333890533447266e+134 iterazioni (se la mia calcolatrice non mi ha mentito). È chiaro che non è possibile convertire in secondi (minuti, ore, giorni, anni). Solo i lontani discendenti vedrebbero il risultato. Il GA lo ha fatto in 1 ora. 20 minuti. Wow. Inoltre, si è scoperto che il coefficiente di correlazione della somma di 50 sinusoidi con la quantità di moto è pari a 0,5275. Perché"inoltre"? Perché non ho mai avuto l'opportunità di verificare questo punto prima d'ora. E in alcuni casi, suggerisce alcuni pensieri.....

Non mi sono fissato sulle sinusoidi, è solo che ho tutto a portata di mano. Inoltre, poiché l'obiettivo è ottenere la massima somiglianza dei segnali continui, il risultato è proprio questa somiglianza, in altre parole, il risultato è inequivocabile, oltre che facilmente verificabile.

Andrey, grazie mille per il tuo prodotto. Mi piacerebbe leggere un altro suo articolo nel prossimo futuro. GA con selezione d'élite. ))

[Andrey Dik]

Alexey_74:
...

Domanda: c'è un modo per spiegare all'algoritmo che (a volte) è possibile terminare prima. Oppure non si dovrebbe fare in modo categorico e si dovrebbe aspettare fino a quando non si raggiunge la convergenza?

È possibile. E persino necessario. Se si sa qualcosa sulla funzione in esame (come nel vostro problema: FF<=1), si dovrebbe utilizzare attivamente questa informazione per evitare calcoli inutili e ridurre così il tempo di ricerca.

In questa implementazione non ci sono leve per controllare l'algoritmo dall'esterno, ma è sufficiente aggiungere una funzione per controllare il flag di arresto forzato.

Nella prossima generazione dell'algoritmo, di cui si sta preparando un articolo di approfondimento, ci saranno molte più possibilità di controllare l'algoritmo dall'esterno (in genere funziona su iniziazione e sotto controllo dall'esterno, e non come è ora - FF è avviato dall'algoritmo stesso, quindi non c'è possibilità di usarlo in gufi auto-ottimizzanti senza modifiche).

[Andrey Dik]

Alexey_74:

....

Andrew, grazie ancora per il tuo prodotto. Vorrei accreditare un altro tuo articolo nel prossimo futuro. GA con selezione d'élite. ))

Grazie per i ringraziamenti. :)

Ci sarà sicuramente un seguito.

E, in bocca al lupo per la ricerca dell'optimum! Nella vita, nel lavoro, nel... Tutto.

[Aleksei Morozov]

Ho paura di chiedere.... )) Ho capito bene? La prossima generazione dell'algoritmo può essere formalizzata come una DLL?

[Andrey Dik]

sì