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
Sì, è vero, solo sotto forma di funzioni standard per ottimizzare la velocità di accesso.
Non credo che si possa ancora parlare di velocità, soprattutto perché MQL5 elabora rapidamente la serie di dati di notizie esistenti. E questo con la speranza che MQL sia ancora più veloce.
Ma vorrei approfondire questo argomento. Mi sto chiedendo cosa pensate di fare dopo con questi dati?
Non credo che si possa ancora parlare di velocità, soprattutto perché MQL5 elabora rapidamente la serie di dati di notizie esistenti. E speriamo che MQL sia ancora più veloce.
Ma vorrei approfondire questo aspetto. Mi chiedo cosa pensano di fare con questi dati in seguito? esempi concreti di utilizzo?
E quello che viene dopo è un campo caldo, le notizie non erano disponibili normalmente prima, e poi la codifica delle strategie di notizie farà boom.
Ho intenzione di usarlo per tutti i comitati NS, ma vorrei sviluppare ulteriormente l'argomento.
ZZZY Ma fino a quando le notizie nel tester non apparirà (cioè, storie di notizie), dovrà fare attraverso i file, e notizie parser su risorse di terze parti.
Il tester rallenta all'aumentare del numero di scambi.
Quando si aprono operazioni con l'intensità di circa 1 operazione ogni 2 minuti si può vedere (scheda Log) che 1 secondo di tempo di test alla fine di un periodo piuttosto lungo ha diverse volte meno operazioni che all'inizio del test. Un'immagine simile quando si producono i risultati dei test in formato Open XML.
In realtà, il tempo di test non dipende direttamente dalla quantità di trade. Per essere precisi, una singola esecuzione con 10 trade richiederà ovviamente meno tempo di un'esecuzione con 100 000 trade perché ogni trade nel tester ha bisogno di tempo per l'elaborazione.
Ma è il numero di zecche elaborate in un passaggio che influisce maggiormente sul tempo di prova. Ho eseguito la media mobile standard in modalità tutti i tick a partire da un mese (intervallo 2009.01.01-2009.02.01) e ho aumentato il tempo di prova di un mese ogni volta fino a 22 mesi.
Come si può vedere dal diagramma, la dipendenza del tempo di test dal numero di tick è strettamente lineare.
Ciao, rifletti l'aggiunta del costrutto
#proprietà tester_indicator "indicator.ex5"
nella documentazione, nella descrizione della funzione iCustom. Ho passato alcune ore a cercare di capire il motivo per cui iCustom funziona nel grafico, ma non funziona nel tester.
Questo è descritto nella sezione delle proprietà del programma.
indicatore del tester
stringa
Nome dell'indicatore personalizzato nel formato "nome_indicatore.ex5" .Gli indicatori necessari per i test sono determinati automaticamente dalla chiamata della funzione iCustom(), se il parametro corrispondente è specificato come una stringa costante. Per altri casi (uso della funzione IndicatorCreate() o uso di una stringa non costante nel parametro che definisce il nome dell'indicatore) abbiamo bisogno di questa proprietà
file tester
stringa
Nome del file per il tester, specificando la sua estensione, racchiuso tra doppi apici (come una stringa costante). Il file specificato sarà passato al tester per il funzionamento. I file di input per i test, se necessari, devono sempre essere specificati
libreria_tester
stringa
Nome della libreria con estensione, racchiuso tra doppi apici. Una libreria può avere sia un'estensione dll che un'estensione ex5. Le librerie necessarie per i test vengono rilevate automaticamente. Tuttavia, se una libreria è usata da un indicatore personalizzato, si dovrebbe usare questa proprietà
Ma hai ragione, è necessario aggiungere esplicitamente le informazioni su di esso di nuovo nei luoghi pertinenti.
In realtà, il tempo di test non dipende direttamente dal numero di scambi. Per essere precisi, una singola esecuzione con 10 operazioni richiederà ovviamente meno tempo di un'esecuzione con 100 000 operazioni, perché ogni operazione nel tester ha bisogno di tempo per essere elaborata.
Ma è il numero di zecche elaborate in un passaggio che influisce maggiormente sul tempo di prova. Ho eseguito la media mobile standard in modalità tutti i tick a partire da un mese (intervallo 2009.01.01-2009.02.01) e ho aumentato il tempo di prova di un mese ogni volta fino a 22 mesi.
Come si vede dal diagramma, la dipendenza del tempo di test dal numero di tick è strettamente lineare.
Probabilmente, dovrei leggere "una singola esecuzione con 10 scambi richiederà ovviamente MENO tempo di un'esecuzione con 100 000 scambi perché ogni scambio nel tester ha bisogno di tempo per essere elaborato.
Sono d'accordo sulle zecche. Ma fate attenzione esattamente al numero di affari - la crescita temporale lì non è ovviamente lineare, e formare un rapporto di prova è completamente fuori questione!
Qual è il tempo massimo che può essere impostato in EventSetTimer( )?
INT_MAX? Non credo. Non voglio indagare da solo, e non c'è nessun aiuto.
Probabilmente si dovrebbe leggere "una singola esecuzione con 10 operazioni richiederà ovviamente MENO tempo di un'esecuzione con 100.000 operazioni, poiché ogni operazione nel tester richiede tempo per essere elaborata.
Sono d'accordo sulle zecche. Ma ancora una volta si prega di prestare attenzione al numero di scambi - la crescita del tempo lì non è chiaramente lineare, e la formazione del rapporto di prova è completamente fuori questione!
Nel processo di test, sono sorte alcune domande, mostro le foto scattate allo stesso tempo:
Come si può vedere dalla figura, solo tre core stanno lavorando, affrontato più di una volta una situazione in cui nel corso del test, il numero di core coinvolti nel lavoro gradualmente sceso a zero, poi è entrato in funzione tutti in una volta, cioè, c'è tempo di inattività, perché i core liberati non iniziano a lavorare immediatamente?
Il numero di corse è definito come 287, i risultati dell'ottimizzazione lo mostrano così, comunque:
cosa significano allora questi numeri? Il numero di punti nel grafico di ottimizzazione è anche circa 381...