Errori, bug, domande - pagina 2438
![MQL5 - Linguaggio delle strategie di trading integrato nel client terminal MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
2. un tipo di frame viene letto in OnTesterPass, finito in OnTesterDeinit. Gli altri frame sono letti in OnTesterDeinit
Questa funzione non ci permette di lavorare in tempo reale con i risultati dei passaggi calcolati se ci sono diversi fotogrammi per passaggio.
Forum sul trading, sistemi di trading automatico e test di strategia
Test dei calendari delle strategie con autosostituzione dei risultati negli EA
Slava, 2013.04.10 15:04
1. Sì, può essere ridondante.
2. un tipo di frame viene letto in OnTesterPass e finito in OnTesterDeinit. I fotogrammi rimanenti sono letti in OnTesterDeinit
Questa capacità di trasmettere-ricevere diversi tipi di frame ci ha permesso di correggere alcuni errori difficili da riprodurre nel tester. E i frame venivano trasmessi solo se c'era una differenza con qualche valore di riferimento.
Prima ho menzionato la perdita di fotogrammi, se molti fotogrammi sono passati in un passaggio e ci sono problemi con l'agente - la connessione è interrotta - si farà qualcosa per questa situazione?
Aprirà l'opt-format?
Sì.
In cambio della pubblicazione del codice per leggere il file opt
Questa funzione non permette di lavorare in tempo reale con i risultati dei passaggi contati se ci sono più fotogrammi per passaggio.
Sì.
Ecco perché dobbiamo leggere i frame di tipo "non-core" dopo che l'ottimizzazione è finita.
Prima ho parlato della perdita di frame, se molti frame sono trasmessi in un solo passaggio e c'è stato un malfunzionamento con l'agente - un'interruzione della comunicazione - verrà fatto qualcosa per questa situazione?
Cosa si può fare?
Ilrisultato dell'ottimizzazione partirà in ogni caso prima e più velocemente della sua cornice. Se l'agente è stato bloccato (spegnimento del computer, servizio fermato), non c'è sicuramente niente da fare.
Potremmo provare a fare così: fino a quando il frame non viene inviato, non inviare il risultato. Ma non si sa quando lo risolveremo.
Questo sembra essere un difetto puramente metodologico
Evitiamo la riallocazione inutile della memoria.
In questo caso c'è il 99% di probabilità che il buffer dell'array venga allocato una volta
Cosa si può fare?
Ilrisultato dell'ottimizzazione partirà comunque prima e più velocemente del suo telaio. Se l'agente è stato messo in stallo (spegnimento del computer, servizio fermato), non c'è esattamente nulla che possiate fare.
Potremmo provare il seguente: finché non viene inviato un frame, non inviare il risultato. Ma non si sa quando lo correggeremo.
Forse prima della trasmissione dei frame, si può dire quanti frame sono attesi, e se è meno del previsto e l'agente non è disponibile, allora dare il passaggio a un altro agente e sovrascrivere i frame già ricevuti?
Oppure nel corpo di ogni fotogramma scrivere il numero totale e il suo numero di sequenza in quel numero, e allo stesso modo, se tutto non è venuto, riottimizzare.Sì.
In cambio della pubblicazione del codice per leggere il file opt
Sono ancora più interessato alla registrazione. Farò la lettura, se il formato è noto.
Si può dire quanti frames sono attesi prima di iniziare a trasmettere, e se ne sono arrivati meno del previsto e l'agente non è disponibile, allora dare il passaggio a un altro agente e sovrascrivere i frames già ricevuti?
O nel corpo di ogni fotogramma per scrivere il numero totale e il suo numero di sequenza in questa quantità, e allo stesso modo, se tutti non è venuto, riottimizzare.E se non tutti i passaggi restituiscono un fotogramma?
Ho dato sopra un esempio di cattura degli errori nel tester. I frame sono stati inviati solo quando qualche valore di risultato non coincideva con il benchmark