Errori, bug, domande - pagina 524
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
Inoltre, per quanto ho capito, la chiusura di un trade con uno stop loss è legata a un trade perdente nel rapporto dei risultati del tester (dove si trova la percentuale di trade perdenti e profittevoli)
Dopo l'aggiornamento alla Build 507, sto avendo due problemi nel tester:
1. Durante l'ottimizzazione, quando si cambia scheda del tester, il terminale si blocca occasionalmente (non sempre);
2. Se un'enumerazione è stata selezionata come parametro ottimizzato, allora quando si cerca di eseguire uno dei risultati dell'ottimizzazione, Expert Advisor non vede il valore di questa enumerazione, cioè è sempre uguale a zero.
Dopo l'aggiornamento alla Build 507, sto avendo due problemi nel tester:
1. Durante l'ottimizzazione, quando si cambia scheda del tester, il terminale si blocca occasionalmente (non sempre);
2. Se un'enumerazione è stata selezionata come parametro ottimizzato, allora quando si cerca di lanciare uno dei risultati dell'ottimizzazione, Expert Advisor non vede il valore di questa enumerazione, cioè è sempre uguale a zero.
Si prega di scrivere a servicedesk con il maggior numero di dettagli possibile.
Sappiamo che c'è un problema con le enumerazioni durante l'ottimizzazione, ma non possiamo riprodurre l'errore in nessun modo
Ho scritto a servicedesk...
Ho accettato la sua domanda e le ho fatto delle domande di controllo
...E qui sorge la domanda (retorica?)...
Ci sono ripetuti calcoli aggiuntivi degli stessi valori nell'indicatore, che ovviamente danno gli stessi risultati. La soluzione sembra essere ovvia: calcolare una volta (quando si accede ai dati storici per la prima volta), mettere tutto nel buffer e negli altri casi applicare ai risultati pronti. Ma...
L'indicatore ha già un numero enorme di buffer (almeno 10 per immagazzinare i dati calcolati dell'intera storia su diversi timeframe) - si accede già con i corrispondenti dati calcolati inizialmente. Ora, come idea e come opzione, c'è la necessità di raddoppiare il numero di buffer.
Naturalmente, tutto questo dipende dalle specifiche hardware: la potenza di elaborazione del processore e la quantità di memoria. E questo è quello che vincerà. Ma prendiamo l'hardware come molto mediocre - non un PC domestico recente. Né troppo né troppo poco. È difficile decidere subito se buttare via la memoria o la potenza di calcolo.
Quindi la domanda a un pubblico esperto: cosa consigliate? Forse ci saranno degli argomenti per l'una o l'altra opzione... O non ingombra la memoria raddoppiando i buffer degli indicatori calcolati, e scalda il processore, calcolando la stessa cosa ogni volta che serve, o viceversa?
Grazie.
...Il che porta alla domanda (retorica?)...
...Naturalmente, tutto si basa sui parametri tecnici dell'hardware: la potenza di elaborazione del processore e la quantità di RAM. E questo è quello che vincerà. Ma consideriamo che l'hardware sia piuttosto mediocre - non un PC domestico recente. Né troppo né troppo poco. È difficile decidere subito se buttare via la memoria o la potenza di calcolo.
...
...E qui sorge la domanda (retorica?)...
Ci sono ripetuti calcoli aggiuntivi degli stessi valori nell'indicatore, che ovviamente danno gli stessi risultati. La soluzione sembra essere ovvia: calcolare una volta (quando si accede ai dati storici per la prima volta), mettere tutto nel buffer e negli altri casi applicare ai risultati pronti. Ma...
L'indicatore ha già un numero enorme di buffer (almeno 10 per immagazzinare i dati calcolati dell'intera storia su diversi timeframe) - si accede già con i corrispondenti dati calcolati inizialmente. Ora, come idea e come opzione, c'è la necessità di raddoppiare il numero di buffer.
Naturalmente, tutto dipende dalle specifiche hardware: la potenza di elaborazione del processore e la quantità di memoria. E questo è quello che vincerà. Ma prendiamo l'hardware come molto medio - non l'ultimo PC di casa. Né troppo né troppo poco. È difficile decidere subito se buttare via la memoria o la potenza di calcolo.
Quindi la domanda a un pubblico esperto: cosa consigliate? Forse ci saranno degli argomenti per l'una o l'altra opzione... O non ingombra la memoria raddoppiando i buffer degli indicatori calcolati, e scalda il processore, calcolando la stessa cosa ogni volta che serve, o viceversa?
Grazie.
In alternativa, perché non usare i database per le vostre esigenze? Calcolato, registrato... è arrivato il momento - estratto nella forma più conveniente, usatelo.
Architettonicamente, la soluzione permette di separare il calcolo e il caching dei risultati.
In alternativa, perché non usare i database per le vostre esigenze? Calcolato, registrato... è il tempo - estratto nella forma più conveniente, usalo.
Architettonicamente, la soluzione permette di separare il calcolo e il caching dei risultati.
Non lo nego, ma la frase "è il momento" suona strana, dato che ogni riferimento sarà riprodotto in OnCalculate ad ogni tick. O il DB deve stare interamente nella RAM, o si dovrebbe accedere lentamente al disco e ridurlo in cenere. Anche se... cosa ne capisco io di DBMS...
Tuttavia, MQL non è un linguaggio di query per DB? Se è così, sta già lavorando con il database dal disco e il disco sembra essere vivo per ora. Non c'è bisogno di inventare nulla di nuovo qui.
Se intendevi un database diverso e un modo specifico (non standard) per accedervi, spiega. Se hai suggerito di integrare l'interazione di MQL5 con qualcos'altro, è troppo presto per me, dato che ho appena iniziato a studiare MLQ e mi sto muovendo verso il kindling avanzato...
Molto spesso la connessione al server si disconnette. Tuttavia, l'indicatore mostra una connessione stabile:
Il terminale non si ricollega. Devo fare il login manualmente. È possibile farlo programmaticamente usando MQL5?