Caratteristiche del linguaggio mql5, sottigliezze e tecniche - pagina 235
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
Se smette di funzionare, sarebbe bene sapere se è corretto.
Se si creano dei puntatori al posto degli oggetti, funzionerà anche la vecchia versione.
Se ha smesso di funzionare, è bene sapere se è la cosa giusta da fare.
Se si creano puntatori invece di oggetti, funzionerà anche la vecchia versione.
Ottima osservazione e grazie per il suggerimento!
Sì, in effetti la situazione è perfettamente risolta con un puntatore:
Gli appassionati di algoritmi veloci. Quelli che lottano per i nanosecondi :)
Compito: trovare l'ora di apertura della barra in base all'ora e al TF indicati, quando si sa che la barra esiste in questo momento. Ad esempio, in base all'orario di apertura e chiusura delle posizioni.
La maggior parte dei programmatori utilizzerà una combinazione di iTime e iBarShift. Questa sarà l'implementazione più lenta, soprattutto perché richiede una cronologia aggiornata dei dati caricati o degli array combinati. Inoltre, questo approccio può generare errori se manca la cronologia richiesta.
I programmatori più avanzati risolveranno questo problema con la struttura MqlDateTime e la funzione TimeToStruct(). Questa non è una cattiva soluzione ed è abbastanza veloce.
Ma esiste una terza soluzione, che è più produttiva della precedente di molte volte:
La difficoltà principale di questo algoritmo è il calcolo dell'ora di inizio del mese (evidenziata in verde) Non cercate di capire il funzionamento dell'algoritmo. C'è una magia, che è il risultato del passaggio dal semplice al complesso. Il percorso inverso, da complesso a semplice, sarà molto più difficile da percorrere.
Il guadagno di prestazioni è dato anche dall'algoritmo che ricava i secondi in una barra dal TF invece che dalla funzione standard PeriodSeconds() - evidenziato in giallo.
Allego uno script di test che calcola e confronta le prestazioni di tutti e tre i metodi:
Il checksum con iBarShift non coincide , perché iBarShift lavora con barre reali. Il checksum coinciderà solo sui timeframe MN1 e W1, perché non ci sono buchi nella storia di tali barre.
Le prestazioni saranno più elevate se si utilizza un piccolo passo temporale nel ciclo (meno di un giorno) quando l'algoritmo inizia a lavorare per salvare i calcoli precedenti:
I valori eccessivi per l'algoritmo tramite iBarShift (evidenziati in blu) sono causati dall'attuale mancanza dello storico necessario o dei TF calcolati dall'array, che ne avvia il caricamento.
Dopo il caricamento il risultato sarà il seguente:
Gli appassionati di algoritmi veloci. Quelli che lottano per i nanosecondi :)
...😮😲😳🥴🤪
...
ah...
mmm....
oooh....
gkghm... Non pensavo che la mia semplice domanda sarebbe uscita in questo modo.
Proprio così.
😮😲😳🥴🤪
...
ah...
mmm.
ohhhh....
ahem. Non pensavo che la mia semplice domanda sarebbe uscita in questo modo.
Oh.
Sì, Artem, mi hai ingannato per un po'.
Era un interesse sportivo.
Spero che possa essere utile a qualcuno, me compreso. :))
Sì, Artem, mi hai imbrogliato per un po'.
Ho lavorato sull'interesse sportivo.
Spero che sia utile a qualcuno, e a me tra gli altri. :))
Certo che lo sarà. Ottimo. Grazie ancora!
S.F. Questo mi ha divertito: "conta correttamente solo fino al 28.02.2100 !!!!".
Cosa facciamo dopo?
Certo che tornerà utile. Ottimo. Grazie ancora!
S.F. Questo mi ha divertito: "conta correttamente solo fino al 28.02.2100 !!!!".
Cosa facciamo dopo?
haha.
Dubito che questo algoritmo sarà richiesto per 75 anni. I computer quantistici probabilmente governeranno già il mondo, con una programmazione completamente diversa.
Ad essere onesti, è stato pigro tenere conto del calendario gregoriano. Il 2000 era una data importante, il 2100 non lo è più.
haha.
Dubito che questo algoritmo sarà richiesto per 75 anni. I computer quantistici probabilmente governeranno già il mondo, con una programmazione completamente diversa.
ad essere onesti, è stato pigro tenere completamente conto del calendario gregoriano. Il 2000 era una posta in gioco alta, il 2100 non lo è più.
Per MN si può usare un array precalcolato, non c'è quasi nulla lì dentro
Ln2(12 mesi * cento anni)... 11 if` e confronti nella ricerca binaria, ma senza altri calcoli.
È possibile utilizzare un array precalcolato per MN, non ci sono praticamente dati.
Ln2(12 mesi * cento anni)... 11 if` e confronti nella ricerca binaria, ma senza altri calcoli.
È possibile utilizzare un array precalcolato per MN, i dati sono praticamente inesistenti.
Ln2(12 mesi * cento anni)... 11 if` e confronti nella ricerca binaria, ma senza altri calcoli.
Ah, ho letto male all'inizio.
No, ti sbagli. L'aumento delle prestazioni non funzionerà. Si rimarrà comunque bloccati nei calcoli. E l'accesso agli elementi dell'array rallenta molto l'algoritmo.