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
Anche così, il codice superiore a volte vince, ma molto raramente, cioè il link è libero
) beh non è così che funziona)
Questo è il modo in cui funziona in C++
Penso che sia lo stesso in mql ma con dei wrapper aggiuntivi da MQ
Forum sul trading, sistemi di trading automatico e test di strategia
FAQ da principianti MQL5 MT5 MetaTrader 5
Romano, 2019.12.11 14:02
Non c'è bisogno di pensarci su, perché dovrei... Il compilatore farà tutto da solo. ))
C# non è C
Date un'occhiata al video su __inline.
Lì si spiega come funzionano le funzioni nella memoria per coloro che non fanno alcuna differenza.
Questo è come funziona in C++
In mql penso che sia lo stesso, ma con dei wrapper aggiuntivi da MQ
Beh, ora rileggere questo thread e un sacco di dichiarazioni ed esempi di test - che c'è qualche differenza. E l'abbiamo trovato)))
Bene ora rileggere questo thread e un mucchio di dichiarazioni ed esempi di test - che c'è una differenza. E hanno fatto))))
No )) Non ho alcun desiderio di rileggerlo.
Per me è ovvio che c'è una differenza.
No )) Non ho alcun desiderio di rileggerlo.
Per me è ovvio che c'è una differenza.
)))) un altro IMHO.
La via superiore è più veloce di quasi il 15% questo è molto significativo, beh se tutto è così ovvio spiegatemelo)
)))) un altro IMHO
Il modo migliore è più veloce di quasi il 20%, beh, visto che è tutto così ovvio spiegamelo)
I cicli confrontati non sono gli stessi in termini di codice nel corpo.
Il primo ciclo ha un codice nel corpo, il corpo del secondo ciclo ha un altro codice.
Naturalmente istruzioni di codice diverse, naturalmente tempi di esecuzione diversi.
Fate lo stesso codice nel corpo del ciclo e cambiate solo la condizione del ciclo ArraySize e la variabile size.
Stiamo testando questa parte, non il corpo.
I cicli che vengono confrontati non sono lo stesso codice nel corpo.
Il primo ciclo ha un codice nel suo corpo e il corpo del secondo ciclo ha un altro codice.
Naturalmente, le istruzioni del codice e il tempo di esecuzione sono diversi.
Fate lo stesso codice nel corpo del ciclo e cambiate solo la condizione del ciclo ArraySize e la variabile size.
Stiamo testando questa parte, non il corpo.
Il tuo test è più scorretto perché dipende dal caso di lancio, eseguilo di nuovo. Qui in entrambi i casi c'è un incremento e una divisione. Beh, in più ci sono un paio di decine~ miliardi di chiamate ArraySize in più.
A proposito, è nel corpo che dovremmo scrivere ciò che stiamo testando. Perché è il corpo che viene ripetuto. Stiamo cercando di avvolgerlo in loop.... per ottenere un risultato cioè in origine era necessariochiamare ArraySize dal corpo
Il tuo test è più scorretto perché dipende dal caso di lancio, eseguilo di nuovo. Qui entrambi i casi hanno un incremento e una divisione. Beh, in più ci sono un paio di decine~ miliardi di chiamate ArraySize sopra.
A proposito, è nel corpo che dovremmo scrivere ciò che stiamo testando. Perché è il corpo che viene ripetuto. Stiamo cercando di avvolgerlo in loop.... per ottenere un risultato cioè inizialmente era necessariochiamare ArraySize dal corpo
Ad ogni iterazione, la condizione del ciclo contiene già un controllo della condizione i<ArraySize() o i<size
, cioè ad ogni iterazione viene chiamata una funzione o una variabile.
Perché dovremmo mettere l'oggetto da testare nel corpo?
La logica stessa ci spinge a decidere quale sarà più veloce da gestire. A una funzione o a una variabile.
Non mi interessa come lo chiama il compilatore. Non mi sto affidando al compilatore, sto solo usando il mio buon senso per capire cosa è più veloce da gestire dal punto di vista dei riferimenti.
Ad ogni iterazione, nella condizione del ciclo, la condizione i<ArraySize() o i<size
è comunque controllata, il che significa che ad ogni iterazione si accede ad una funzione o ad una variabile.
Perché dovremmo mettere l'oggetto da testare nel corpo?
Perché noi siamo i fortunati che hanno questa funzione e la funzione può essere qualsiasi altra. Ed è collocato esattamente nel corpo. L'ho solo duplicato nel tentativo di migliorarne l'effetto rivolgendosi a diverse matrici.
Ma è sbagliato aggiungere compiti più complicati, il cui errore di calcolo può mettere in ombra l'effetto studiato. Tra l'altro è anche possibile che l'assemblaggio non sia costante in μl. cioè quando si ricompila può ottenere dati leggermente diversi (anche se questo non è esatto, ma è un po' usato come protezione contro l'hacking) Quindi tutto può essere testato sul tuo codice per te. Vedi se i risultati cambiano.
Mcl cerca semplicemente di sostituire il codice come indicato nel video. Beh, lì è un po' diverso. Ma in termini generali.
E quelle istruzioni di funzioni che non sanno quale valore otterranno - questo è il modo in cui lavorano js e php e altri linguaggi simili, anche µl funziona così ma solo in modalità debug
Ad ogni iterazione, nella condizione del ciclo, la condizione i<ArraySize() o i<size
è comunque controllata, il che significa che ad ogni iterazione si accede ad una funzione o ad una variabile.
Perché dovremmo mettere l'oggetto da testare nel corpo?
La logica stessa ci spinge a decidere quale sarà più veloce da gestire. A una funzione o a una variabile.
Non mi interessa come lo chiama il compilatore. Non mi affido al compilatore, mi affido al buon senso e capisco cosa è più veloce da gestire dal punto di vista dei riferimenti.
Non funziona sempre.
Forum sul trading, sistemi di trading automatico e test di strategie di trading
Domanda per gli esperti di #define
Romano, 2020.11.02 19:44
Ho cambiato il mio post.
È il contrario, cioè ArraySize è più veloce di cnt.
Prima era viceversa. Forse l'incremento cnt influisce, il corpo del ciclo è diverso e probabilmente bisogna inventare qualcos'altro per il carico.