Errori, bug, domande - pagina 1998

 
Stanislav Korotky:

Questo è l'argomento che non capivo (quando era proposto da MQ) e che non capisco ora. L'inizializzazione non va da nessuna parte. Ora è affidato al programmatore dell'applicazione e lo fa comunque, ma come dimostra la pratica, a volte con errori. Se fosse fatto da un kernel, le prestazioni non ne risentirebbero e non ci sarebbero errori.

Prendiamo, per esempio, l'array del buffer dell'indicatore: quando si inizializza l'indicatore, il buffer ha una lunghezza zero. Cosa c'è da inizializzare con degli zeri? Quando viene aggiunto un altro indice, è forzato ad essere azzerato e poi riempito con qualche valore? A cosa serve questo azzeramento o riempimento con EMPTY_VALUE? E se c'è bisogno di assegnare PLOT_EMPTY_VALUE e non 0 o EMPTY_VALUE o di forzare uno, ma abbiamo bisogno di un altro... In qualunque modo la si tagli, si finisce per perdere il proprio tempo...

E un array personalizzato... L'array è dichiarato per qualche dato diverso da zero e EMPTY_VALUE. Quindi perché dovrebbe essere forzatamente inizializzato con qualcosa?

Così si scopre che influisce sulle prestazioni nella maggior parte dei casi.

 
Alexey Viktorov:

Ma un array personalizzato... L'array è dichiarato per qualche dato diverso da zero e EMPTY_VALUE. Allora qual è lo scopo di inizializzarlo forzatamente con qualcosa?

Per avere meno "i risultati del tester non corrispondono".

 
fxsaber:

Per rendere meno "i risultati dei tester non corrispondono".

Chi ne ha bisogno?

Scrivi un articolo che dica in ogni paragrafo che non dovresti ordinare EAs da chiunque. Dovete scrivere correttamente i vostri EA.

 
Alexey Viktorov:

Chi ne ha bisogno?

Io e, sono abbastanza sicuro, gli sviluppatori.

 
fxsaber:

Per me e, sono abbastanza sicuro, per gli sviluppatori.

Dubito molto che una tale sciocchezza possa metterti in difficoltà. O questo o c'è un'altra ragione.

 
Alexey Viktorov:

Dubito molto che una cosa così insignificante ti possa bloccare. O la ragione è qualcos'altro.

Anche se ho scritto perfettamente (senza fare errori - il che non è il caso), è normale prendere la libreria di qualcuno (a volte senza codice sorgente - nel Marketplace) e usarla, sperando che sia scritta con competenza. E non c'è nessuna assicurazione che dopo si possa incorrere in risultati diversi nel tester. E trovare la vera causa sarà MOLTO difficile. E ripararlo è a volte impossibile.

L'obiettivo è che da esecuzione a esecuzione il risultato sia riproducibile - identico, anche con un errore.

 
fxsaber:

Probabilmente la soluzione ideale sarebbe forzare l'inizializzazione per tutti i programmi di default + un interruttore di compilazione per disabilitarla (per coloro che sono sicuri e vogliono accelerare di un paio di punti percentuali).

 

L'inizializzazione richiede davvero molte risorse. Ho buttato via un pezzo di codice con inizializzazione forzata e ho ottenuto quasi 2 volte più veloce nell'ottimizzazione)

E mi sono imbattuto in una cosa interessante. Com'è possibile che il drawdown sia del 120% e allo stesso tempo il risultato sia al top e plus?

Quando provo la strategia ottengo un drawdown del 109% e nessuna chiamata di margine, mentre il saldo continua a crescere.
 
Anton Ohmat:

L'inizializzazione richiede davvero molte risorse. Ho buttato fuori un pezzo di codice con inizializzazione forzata - ha accelerato nell'ottimizzazione di quasi 2 volte)

Qualcosa che hai scritto in modo errato.

 
Andrey Khatimlianskii:

L'inizializzazione completa non è sempre necessaria. Per esempio, per un indicatore che riempie il valore del buffer per ogni barra nel ciclo (e lo fa indipendentemente dal fatto che il buffer dell'indicatore sia inizializzato o meno).

In questo caso sarà più economico senza azzeramento forzato.

E perché inventare scenari così irrealistici, di fatto errori del programmatore MQL? Ovviamente, l'inizializzazione completa viene fatta solo una volta, o quando viene rilevato il pompaggio dei dati. In questo caso, sarebbe più efficiente se fosse il kernel a farlo.