Ottimizzazione nel tester di strategia - pagina 10

Nuovo commento
 

Nelle ultime build ci siamo sbarazzati completamente degli overhead di sistema sui task, riducendoli da quasi 2000 ms a zero.

Ecco i risultati dell'esecuzione di un compito di calcolo, che è stato suggerito da joo:

input double   x1=0.0;
input double   x2=0.0;
double OnTester()
  {
   return
   (
    pow(cos((double)(2*x1*x1))-0.11 e1,0.2 e1)+
    pow(sin(0.5 e0 *(double) x1)-0.12 e1,0.2 e1) -
    pow(cos((double)(2*x2*x2))-0.11 e1,0.2 e1)+
    pow(sin(0.5 e0 *(double) x2)-0.12 e1,0.2 e1)
    );
  }

Impostazioni (le date sono impostate di proposito in modo che la storia del grafico non venga utilizzata):

Parametri da eseguire:

Agenti utilizzati (4 agenti locali):

Risultati dell'ottimizzazione:

L'ottimizzazione ha richiesto solo 25 secondi, sono stati fatti 18.432 passaggi:



Risultato complessivo: MetaTrader 5 e la sua rete di agenti possono essere utilizzati per massicci calcoli matematici.

 
Renat:

Nelle ultime build ci siamo sbarazzati completamente degli overhead di sistema sui task, riducendoli da quasi 2000 ms a zero.

Ecco i risultati dell'esecuzione di un compito di calcolo, che è stato suggerito da joo:

Impostazioni (le date sono impostate di proposito in modo che la storia del grafico non venga utilizzata):

Parametri da eseguire:

Agenti in uso (4 agenti locali):

Risultati dell'ottimizzazione:

L'ottimizzazione ha richiesto solo 25 secondi e sono stati fatti 18.432 passaggi:

Il risultato complessivo: MetaTrader 5 e la sua rete di agenti possono essere utilizzati per massicci calcoli matematici.

Questo è un ottimo risultato. Ora l'ottimizzatore è davvero più o meno adatto per compiti di ottimizzazione (sia relativi al trading che non). I risultati saranno ancora migliori se il numero di passaggi sarà ridotto a 2-3 migliaia per questo compito specifico con le impostazioni predefinite dell'ottimizzatore GA, ma per questo è necessario visualizzare le impostazioni GA per l'accesso dell'utente (sarà possibile ridurre il numero di passaggi a 500-900 se l'utente vuole).

Rimane un problema legato alla limitazione dello spazio di ricerca. Una proposta di ottimizzatore corrispondente è stata fatta in servicedesk.

 
joo:

Questo è un ottimo risultato. Ora l'ottimizzatore è davvero più o meno adatto per compiti di ottimizzazione (sia di trading che non direttamente legati al trading). Risultati ancora migliori sarebbero se il numero di passaggi fosse ridotto a 2-3 mila per questo compito specifico con le impostazioni GA di default dell'ottimizzatore, ma per questo è necessario rendere le impostazioni GA disponibili all'utente (sarà possibile ridurre il numero di passaggi a 500-900 se l'utente vuole).

Rimane un problema legato alla limitazione dello spazio di ricerca. Una proposta di ottimizzatore corrispondente è stata fatta nel service desk.

E la soluzione a questo problema è principalmente legata a questo problema:

Se l'overflow dei passaggi di ottimizzazione avviene già su 4 parametri, allora parlare di aumentare il numero di parametri più di quanto consentito ora (64) non è ancora appropriato.

 
Urain:

E la soluzione di questo problema è principalmente legata a questo problema:

Se l'overflow di ottimizzazione avviene già su 4 parametri, allora parlare di aumentare il numero di parametri più di quanto consentito ora (64) non è ancora appropriato.

Naturalmente. Approssimativamente, lo spazio di ricerca è P=n*step, dove n-numero di parametri da ottimizzare e step-step del parametro. Allo stesso tempo, P dovrebbe essere più piccolo di Pmax (massimo spazio di ricerca possibile, limitato dalle caratteristiche della codifica binaria del cromosoma). Pertanto, una delle restrizioni introdotte artificialmente (per esempio, si può fare un limite di 10000 parametri, ma poi il passo sarà più del necessario per risolvere la maggior parte dei problemi di ottimizzazione), in modo che P non superi Pmax, è stata introdotta una restrizione su n.

I pensieri su questo sono espressi nella proposta di ottimizzatore in servicedesk.


PS Con la crescita delle reti di agenti remoti, il problema del numero elevato di esecuzioni sta venendo meno. Ma, naturalmente, solo se vengono rimosse le restrizioni della codifica binaria dei cromosomi (leggi - passare alla codifica dei cromosomi con numeri reali).

 
joo:

Naturalmente. Approssimativamente, lo spazio di ricerca è P=n*step, dove n-numero di parametri da ottimizzare e step-step del parametro. Quindi, P dovrebbe essere più piccolo di Pmax (massimo spazio di ricerca possibile, limitato dalle caratteristiche della codifica binaria del cromosoma). Pertanto, una delle restrizioni, introdotte artificialmente (per esempio, si può fare un limite di 10000 parametri, ma poi il passo sarà più del necessario per risolvere la maggior parte dei problemi di ottimizzazione), che P non andrebbe oltre Pmax, è stato introdotto un limite su n.

Riflessioni su questo sono date nella proposta dell'ottimizzatore in Service Desk.


PS Man mano che le reti di agenti remoti crescono, il problema dei grandi numeri di corse sparisce. Ma naturalmente, solo se le restrizioni della codifica binaria dei cromosomi vengono rimosse (leggi: passare alla codifica dei cromosomi con numeri reali).

Leggermente sbagliato, il numero corretto di varianti è P=step_0*step_1*...*step_n

che, se la dimensione del passo è uguale, risulta in P=step^n

 
Urain:

Leggermente sbagliato, il numero corretto di scelte è P=step_0*step_1*...*step_n

che, se la dimensione del passo è uguale, risulta in P=step^n

Beh, sì, hai ragione, sto solo dicendo - più o meno, per essere più chiaro ed evidente, cosa dipende da cosa.
 
Renat:

Nelle ultime build, abbiamo completamente eliminato i sovraccarichi di sistema all'avvio delle attività, riducendoli da quasi 2000 ms a zero.

Fantastico! Ah, quanto tempo è stato sprecato durante l'estate per l'ottimizzazione...

Prima le cose importanti. Ho eseguito il test di joo sulla build attuale e sulla build 319 (02 settembre 2010). risultati:

2010 12/229 15:49:18 Tester superato in 2 minuti e 41 secondi
2010.12.29 15:49:18 Ottimizzazione del tester terminata al passaggio 15360 (di 100000020000001)
2010.12.29 15:49:18 La cache dei risultati del test è stata utilizzata 7265 volte
2010.12.29 15:49:13 La genetica dei tester è finita
2010.12.29 17:10:59 Ottimizzazione del tester superata in 1 ora 17 minuti 34 secondi
2010.12.29 17:10:59 Ottimizzazione genetica del tester terminata al passaggio 18176 (di 100000020000001)
2010.12.29 17:10:59 La cache dei risultati del test è stata utilizzata 10582 volte
2010.12.29 17:10:52 La genetica dei tester è finita

Non so nemmeno se congratularmi o ringraziare. Grazie!

 
Urain:

E la soluzione a questo problema ha a che fare con questo problema in primo luogo:

Se l'overflow dei passaggi di ottimizzazione si verifica già su 4 parametri, allora parlare di aumentare il numero di parametri più del consentito ora (64) non è ancora appropriato.

Usate un approccio ragionevole alla ricerca, ma non girate le manopole al massimo in modalità "uomini russi rompono la motosega giapponese".

Non appena si inizia ad applicare l'ottimizzazione genetica nel lavoro reale, si inizia immediatamente a scegliere limiti ragionevoli.

 
Yedelkin:

Fantastico! Eh, quanto tempo è stato sprecato durante l'estate per l'ottimizzazione...

In ordine. L'ho testato sulla build attuale e sulla 319a build (02 settembre 2010):

2010.12.29 15:49:18 Ottimizzazione del tester passata in 2 minuti e 41 secondi
2010.12.29 15:49:18 Ottimizzazione genetica del tester finita al passo 15360 (di 100000020000001)
2010.12.29 15:49:18 La cache dei risultati del tester è stata usata 7265 volte
2010.12.29 15:49:13 La genetica del tester è finita
2010.12.29 17:10:59 Ottimizzazione del tester passata in 1 ora 17 minuti 34 secondi
2010.12.29 17:10:59 La genetica del tester è finita al passo 18176 (di 100000020000001)
2010.12.29 17:10:59 La cache dei risultati del tester è stata usata 10582 volte
2010.12.29 17:10:52 La genetica del tester è finita

Non so se congratularmi o ringraziare. Grazie!

Si noti che abbiamo ridotto l'overhead del sistema nelle fasi di "sincronizzazione/trasmissione dei dati iniziali dal terminale all'agente e ricezione dei risultati dall'agente", il che ha portato a un risparmio di 1,5-2 secondi per esecuzione. Non c'era alcuna accelerazione dei calcoli nella lingua stessa.

Cioè, l'effetto più grave è nei calcoli ad alta velocità, dove il calcolo richiede un tempo vicino allo zero. Per i calcoli massicci i risparmi non sono così pronunciati. Anche se un risparmio di 2 secondi per 10.000 corse dà 20.000 sec = 333 minuti = 5,5 ore.

 
Renat:
Non lo fa.

Ho notato che ha un effetto. Ho eseguito l'EA nei giorni feriali e l'ho eseguito ora con spread esteso, il risultato è abbastanza diverso, lo spread è di circa 4 pip (quattro cifre) su Eurobuck ora. Anche in mt5 c'è un po' di inceppamento dello spread nel fine settimana, quindi non voglio eseguirlo nel fine settimana, perché l'ottimizzazione non sarà corretta. Posso anche vederlo visivamente in mt4 dove un EA si sta ottimizzando da lunedì e la curva dei risultati è scesa dal fine settimana; ciò dimostra che lo spread influenza i risultati di ottimizzazione, sono diventati peggiori.

1...34567891011121314151617...19
Nuovo commento