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
No, Vladimir. È un po' sbagliato.
In questo caso, dovreste applicare ArraySetAsSeries(array, false); a un array di trecento elementi tra i quali è considerato iMAOnArray(). Ma è meglio usare CopyOpen() invece del ciclo di riempimento dell'array.
Da quanto ho capito, in questa variante sarà meglio
No, Vladimir. È un po' sbagliato.
In questo caso, dovreste applicare ArraySetAsSeries(array, false); a un array di trecento elementi tra i quali è considerato iMAOnArray(). Ma è meglio usare CopyOpen() invece del ciclo di riempimento dell'array.
Da quanto ho capito, in questa variante sarà meglio
Questa è la domanda. Se non ho bisogno di calcolare l'intero array, ma solo gli ultimi N elementi.
Non capisco bene la logica del calcolo di queste funzioni quando si limita. Ho un array di serie temporali (uno dei buffer degli indicatori), se lascio il numero di elementi uguale a 0, nessuna domanda, tutto viene contato e calcolato, ma se diminuisco il numero di elementi coinvolti nel calcolo degli stessi offset, ottengo solo quelli primari. In parole povere c'è un array di 5000 elementi (barre sul grafico), per risparmiare tempo ho bisogno di calcolare solo gli ultimi 300, ma quando ho specificato il valore 300 nel secondo parametro ho ottenuto 5000-4700 elementi primari, ma sull'offset 300-0, e gli ulteriori valori ad una chiamata non cambiano. Che senso ha usare questo parametro?
Il diavolo lo sa. Dimenticalo e basta. Se avete bisogno di accelerare i calcoli, riducete il numero di elementi da calcolare nel vostro ciclo.
Una delle due cose: o è impossibile o hai bisogno di una qualche combinazione segreta di direzioni di calcolo delle serie temporali e non delle serie temporali.
Chi cazzo lo sa. Lascia perdere. Se volete accelerare i calcoli, riducete il numero di elementi da calcolare nel vostro ciclo.
Una delle due cose: o è impossibile o hai bisogno di qualche combinazione segreta di serie temporali, non serie temporali, direzione di calcolo.
Sì, come ho già scritto un po' prima, c'è solo una possibilità - usare i propri analoghi delle funzioni di cui sopra, che possono essere usati per calcolare almeno un elemento.
Il paradosso della situazione è che se facciamo un modello simile, sovrapponendo la media o le barre di bollinger su qualsiasi indicatore (linea di prezzo), non ci sarà un tale rallentamento del calcolo iniziale di tutte le barre della storia, come quando si usano queste funzioni nel codice, quando si riavvia il terminale o si cambia il TF, quindi non è chiaro, cosa ci vuole così tanto tempo per essere calcolato in queste funzioni.
Chi cazzo lo sa. Lascia perdere. Se volete accelerare i calcoli, riducete il numero di elementi da calcolare nel vostro ciclo.
Una delle due cose: o è impossibile o hai bisogno di una qualche combinazione segreta di direzioni di calcolo delle serie temporali e non delle serie temporali.
Anche io ho usato una tale costruzione.
A proposito,"MovingAverages.mqh" è due volte più veloce di"iMAOnArray", anche la vecchia versione.
https://www.mql5.com/ru/forum/79988
Sì, come ho scritto poco prima, c'è solo un'opzione - usare i nostri analoghi delle funzioni menzionate dove è possibile calcolare almeno un elemento.
Il paradosso della situazione è che se facciamo un modello simile attaccando la MA e le bande di Bollinger a qualsiasi indicatore (linea di prezzo), non vedremo un tale rallentamento del calcolo iniziale di tutte le barre storiche, come quando si usano queste funzioni nel codice, quando si riavvia il terminale o si cambia il TF, quindi non è chiaro cosa ci voglia così tanto tempo per il calcolo in queste funzioni.
Sta rallentando anche quando si usa iMAOnArray? Non dovrebbe esistere una cosa del genere. Come voi, c'era un ritardo da StdOnArray (o BandsOnArray, non ricordo) gli sviluppatori non hanno ammesso l'esistenza del bug per molto tempo. Poi all'improvviso è stato aggiustato e ha funzionato velocemente. Chi lo sa, forse il bug è tornato. Se anche iMAOnArray() causa notevoli rallentamenti, si tratta di un bug. Sembra che se ne sia parlato un paio di mesi fa... Ma è ancora lì, a quanto pare.
Il rallentamento anche dall'uso di iMAOnArray? Non dovrebbe essere così. Come voi una volta, c'era un rallentamento da StdOnArray, gli sviluppatori non hanno riconosciuto il bug per molto tempo. Poi l'hanno improvvisamente aggiustato e ha funzionato velocemente. Chi lo sa, forse il bug è tornato. Se anche iMAOnArray() causa notevoli rallentamenti, si tratta di un bug. Sembra che se ne sia parlato un paio di mesi fa... Ma è ancora lì, a quanto pare.
È difficile giudicare se è troppo lento o no, perché tutto dipende dalla lunghezza del grafico (numero di barre), il problema è che per l'ottimizzazione devi calcolare solo un po', e non puoi limitare la lunghezza del calcolo con il calcolo effettivo.
Fate il calcolo conMovingAverages.mqh e il calcolo sarà molto veloce.
Quindi mostrami la variante "funzionante" del codice, il codice originale è qui, che stai cercando di ridurre a 12 elementi visualizzati invece dei trecento richiesti da me, e dovrebbe finire con 3 buffer di indicatori con i dati specificati, in modo che almeno 300 elementi siano stati visualizzati nel seminterrato, E poi, quando arriva una nuova barra, rispettivamente, 301 e poi il valore sarà disegnato, ma non dimenticate che in questo caso, se usate 0 come limite per il calcolo, solo la nuova barra sarà ricalcolata, e il tipo di media (smoothing) per il secondo buffer non è necessariamente SMA, e può essere qualsiasi dei 4 disponibili.
Ecco a voi.