Errori, bug, domande - pagina 672
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
Quante barre ci sono nella finestra?
Il problema è che non si libera memoria nel terminale quando il TF viene commutato. Avvia Task Manager, lancia l 'indicatore sul grafico e guarda la memoria crescere. Poi passate ad un altro TF e vedrete la memoria ricominciare a crescere. Ma logicamente, quando si passa a un altro TF, i dati del TF precedente dovrebbero essere scaricati dalla memoria. Poiché i dati del precedente TF non vengono cancellati, la memoria cresce fino a quando non si riavvia e genera un errore. Se rimuovi il tuo indicatore dal grafico, vedrai che dopo un certo periodo di tempo la memoria viene cancellata. Ma non viene cancellato mentre l'indicatore è in funzione.
La mia opinione: la soluzione a questo problema è ServiceDec.
Grazie, cancellerò l'indicatore prima di cambiare il TF. Inoltre ho ridotto le barre massime nella finestra da 2000000 a 1000000 apparentemente MetaDriver vuole dirmi questo.
Finora sembra funzionare.
Grazie, cancellerò l'indicatore prima di cambiare il TF. Inoltre, ho ridotto il numero massimo di barre nella finestra da 2000000 a 1000000, apparentemente MetaDriver vuole dirmi questo.
Finora sembra funzionare.
Perché hai bisogno di 100.000? 100.000 sono sufficienti per me, è quello che sto cercando di dirti.
Non limita in alcun modo i test di profondità.
Limita solo (1) la visualizzazione in finestre (2) la dimensione dei buffer degli indicatori.
Ho limitato a lungo e deliberatamente la "storia visibile". Il risultato - non ho problemi di memoria.
Perché hai bisogno di un milione? 100.000 va bene per me, che è esattamente quello a cui stavo alludendo.
Non limita in alcun modo i test a nessuna profondità.
Limita solo (1) la visualizzazione nelle finestre (2) la dimensione dei buffer degli indicatori.
Ho limitato a lungo e deliberatamente la "storia visibile". Il risultato è che non ho problemi di memoria.
Sì, grazie, ho intenzione di utilizzare 108 coppie a InstaForex ancora di più, in modo da non avere problemi di memoria.
Questo è un bell'argomento. Nei primi giorni di MT5 urlavo che tutti gli indicatori dovrebbero avere un nuovo parametro standard - il numero di barre da calcolare.
Altrimenti otteniamo l'unico limitatore - TERMINAL_MAXBARS. Questo non è accettabile per gli Expert Advisor che analizzano molti simboli in tempo reale usando indicatori. Nella maggior parte dei casi (99%) ho bisogno in Expert Advisors di un numero strettamente specificato delle ultime barre E TUTTE. Tutto il resto è troppo per me. Naturalmente non solo per me...
È stato ignorato. Di conseguenza, ho trasferito tali calcoli nel codice del mio Expert Advisor.
Ah sì, e l'apparizione di molte toppe auto-scritte. Alcuni articoli intelligenti sono stati anche scritti e pubblicati, come il seguente:
Diminuire il consumo di memoria per gli indicatori ausiliari
Implementazione degli indicatori come classi con esempi di Zigzag e ATR
...
Se si separano gli indicatori visualizzati regolari e gli indicatori calcolati corti, sarà facile ottenere divergenze sugli indicatori cumulativi lunghi.
Anche questo porterà a pericolose stampelle dalla nostra parte.
Un buon modo è impostare 100000 barre per grafico o passare a x64.
Renat:
Индикаторы на короткой истории нельзя рассчитывать, так как они являются общим разделяющимся между всеми процессами (терминал, окна, эксперты) ресурсом. Причем на индикаторах действуют множество правил обновления, синхронизации и пересчета рыночного окружения.
Если разделить штатные отображаемые индикаторы и короткие расчетные, то легко будет получить расхождение на длинных кумулятивных индикаторах.
Так же это приведет к опасным костылям на нашей стороне.
Хороший способ - устанавливать 100000 баров на чарт или переходить на х64.
In generale, non cambia nulla. Le richieste per la possibilità di limitare la dimensione dei buffer degli indicatori in MQL5 sono respinte, e se il vostro programma inizia a consumare una quantità enorme di memoria a causa dei molti buffer degli indicatori utilizzati - allora si chiama "errore di programmazione".
"In Expert Advisors, il più delle volte (99%) ho bisogno di un numero strettamente specifico di ultime barre E TUTTE. Tutte le cose inutili sono troppo per me. Non solo io, naturalmente..." (с)
2) Gli indicatori non possono essere contati su una storia breve, perché sono una risorsa condivisa tra tutti i processi (terminale, finestre, esperti). E ci sono molte regole di aggiornamento, sincronizzazione e ricalcolo dell'ambiente di mercato sugli indicatori.
3. Se si separano gli indicatori visualizzati regolari da quelli calcolati corti, sarà facile ottenere divergenze sugli indicatori cumulativi lunghi.
Anche questo porterà a pericolose stampelle dalla nostra parte.
1. un buon modo è impostare 100000 barre per grafico o passare a x64.
1. Questo è quello che ho fatto. Eppure, è un compromesso scomodo. Idealmente, se mi distraggo completamente dai problemi di sviluppo (puramente come utente) mi piacerebbe avere una scelta quando si imposta la lunghezza del calcolo. Per il grafico - l'intera lunghezza (anche se non sempre, ci sono gravi e grandi eccezioni), per gli esperti - esattamente il tempo necessario. 3.
2. Come sviluppatore, capisco le difficoltà e i limiti simultanei di questo approccio, e tuttavia il consumo di memoria è anche il mio problema, e non vuole ostinatamente cadere in secondo piano. Ho un suggerimento-soluzione concreto: considerare il periodo di calcolo (chiamiamolo così) come un parametro uguale , non peggiore degli altri. Allora due indicatori con tutti i parametri simili, ma con un periodo di calcolo diverso, sono semplicemente due indicatori diversi. Sì, teoricamente ci sono casi d'uso stupidi che possono portare a spese aggiuntive (se l'utente moltiplicherà i periodi di calcolo), ma in pratica è improbabile. Se qualcuno vuole andare avanti con questo, è colpevole. Proprio come ora TUTTI gli utenti sono colpevoli di "aver aperto troppi indicatori e non si sono preoccupati di ridurre TERMINAL_MAXBARS".
So che nel calcolo dell'EMA si utilizzano tutte le barre dall'inizio del tempo, ma so anche che nello stocastico, nell'RSI e in un numero enorme(predominante) di altri indicatori il calcolo viene eseguito su una lunghezza organica . E questa conoscenza mi permette la flessibilità di scegliere il periodo di calcolo (MaxBar). Datemi una scelta.
Tanto quanto ora è colpa di TUTTI gli utenti che "aprono troppi indicatori e non fanno attenzione a ridurre TERMINAL_MAXBARS".
Sì, specialmente in condizioni di campionato quando non si può influenzare affatto la dimensione di TERMINAL_MAXBARS.
1. L'ho fatto. Eppure, è un compromesso scomodo. Idealmente, se ci distogliamo completamente dai problemi di sviluppo (puramente come utente) mi piacerebbe avere una scelta quando si imposta la lunghezza del calcolo. Per il grafico - l'intera lunghezza (anche se non sempre, ci sono gravi e grandi eccezioni), per gli esperti - esattamente il tempo necessario. 3.
2. Come sviluppatore, capisco le difficoltà e i limiti simultanei di questo approccio, e tuttavia il consumo di memoria è anche il mio problema, e non vuole ostinatamente cadere in secondo piano. Ho un suggerimento-soluzione concreto: considerare il periodo di calcolo (chiamiamolo così) come un parametro uguale , non peggiore degli altri. Allora due indicatori con tutti i parametri simili, ma con un periodo di calcolo diverso, sono semplicemente due indicatori diversi. Sì, teoricamente, ci sono varianti stupide che possono portare a spese aggiuntive (se l'utente moltiplica i periodi di calcolo), ma in pratica è improbabile. Se qualcuno vuole andare oltre questo dosso - è colpa sua. Proprio come ora TUTTI gli utenti sono colpevoli di "aver aperto troppi indicatori e non si sono preoccupati di diminuire TERMINAL_MAXBARS".
So che nel calcolo dell'EMA si usano tutte le barre dall'inizio del tempo, ma so anche che nello stocastico, nell'RSI e in un numero enorme(predominante) di altri indicatori si calcolano su una lunghezza organica . E questa conoscenza mi permette la flessibilità di scegliere il periodo di calcolo (MaxBar). Datemi una scelta.
Il messaggio è chiaro.
Noi stessi vogliamo ridurre il consumo di risorse. Forse la soluzione può essere qualche funzione IndicatorMaxDepth(uint len) che agirà solo sugli indicatori creati in questo EA.
Ma il problema è che durante i test, i buffer degli indicatori in modalità di accumulazione cresceranno insieme alla storia e non ci sarà alcun salvataggio. Ritagliare la storia dell'indicatore in tempo reale, mantenendo la profondità specificata è irto di bei glitch e fa saltare la testa ai programmatori, che contano/abituati al sincronismo delle barre del grafico e del buffer dell'indicatore.
Un'opzione migliore è passare a x64.
Rivedremo la cache degli indicatori, che ora utilizza il principio della massima efficienza contro il principio del risparmio di memoria. Cercheremo di scaricare immediatamente gli indicatori che sono stati rifiutati, invece di tenerli in memoria per qualche tempo, come facciamo ora. Questo renderà possibile chiamare centinaia di indicatori in fila con uno scarico diretto attraverso IndicatorRelease.
Naturalmente, se qualcuno chiamerà centinaia di indicatori nella modalità di scansione del mercato senza scaricarli, allora deve andare direttamente alla versione a 64 bit + installazione di memoria aggiuntiva.
Ora è strano fare test massicci seduti su x32. Qualsiasi computer x64 decente con 16GB di memoria (senza essere fanatici di schede grafiche e monitor) può essere comprato per 15.000 rubli.