Caratteristiche del linguaggio mql5, sottigliezze e tecniche - pagina 136
![MQL5 - Linguaggio delle strategie di trading integrato nel client terminal MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Quindi sei disposto ad accendere una banconota da 100 dollari per trovare una monetina arrotolata sotto il letto?
Può essere o non essere una moneta
La probabilità di un dieci è doppia. E soprattutto, l'affermazione di costosità di get_rand() viene succhiata dalla mano, quindi perché ottenere numeri casuali dalla porta di servizio con una probabilità spostata (mentre ci si aspetta una distribuzione uniforme) quando si può avere una distribuzione normale? Non stai salvando una banconota da 100 dollari, stai salvando dei fiammiferi.
Può essere o non essere una moneta
La probabilità di un dieci è doppia. E soprattutto, l'affermazione di costosità di get_rand() viene succhiata dalla mano, quindi perché ottenere numeri casuali dalla porta di servizio con una probabilità spostata (mentre ci si aspetta una distribuzione uniforme) quando si può avere una distribuzione normale? Non stai salvando una banconota da 100 dollari, stai salvando dei fiammiferi.
Sì, mi sbagliavo sull'alta lentezza della vostra funzione. Ho frainteso l'algoritmo. Mi dispiace.
Ma ancora il mio algoritmo è il più veloce di tutti quelli proposti, nonostante il fatto che sia più universale e non limitato a 32767, come il tuo.
Codice per provarlo.
Questo script genera casualmente un array di punti con colore e coordinate casuali. La dimensione dell'array è uguale al numero di pixel del grafico. Si ripete 5 volte
Ho raccolto i numeri in modo tale da mostrare l'essenza del problema, quando applichiamo rand()%20000
come dovrebbe essere:
Ma il 99,9% delle volte, questa funzione funzionerà ugualmente: funzionerà ancora più velocemente.Questa funzione genererà un numero casuale da 0 a 1073741824. Questo numero è anche maggiore del numero di tick per qualsiasi strumento su tutta la storia. La "slealtà" di una tale funzione sarebbe microscopica per il 99,9% dei compiti.
Ma ancora il mio algoritmo risulta essere il più veloce di tutti gli algoritmi proposti, nonostante il fatto che sia più universale e non limitato a 32767 come il tuo.
Il codice come prova.
Grazie per il lavoro, risultati davvero interessanti. Si scopre che la funzione rand() è così veloce che funziona più velocemente delle operazioni aritmetiche.
Grazie per lo sforzo, risultati davvero interessanti. Si scopre che rand() è così veloce che è più veloce delle operazioni aritmetiche.
No, non lo è. Circa un nanosecondo, proprio come estrarre la radice quadrata da un numero doppio. Le operazioni +-*/ sono eseguite in frazioni di nanosecondo.
Ma proprio come la radice quadrata, rand() viene eseguita nei processori moderni a livello hardware, non programmaticamente.
No, non più veloce. Circa un nanosecondo, proprio come estrarre la radice quadrata da un numero doppio. Le operazioni +-*/ sono eseguite in frazioni di nanosecondo.
Ma proprio come la radice quadrata, rand() viene eseguita nei processori moderni a livello hardware, non programmaticamente.
La tua versione differisce dalla mia in quanto rand() è sempre chiamata 5 volte mentre la mia ha una media di 1,64 volte a 20 000 range e 1 volta a 256. Complessivamente rand() è chiamata 25 volte per ogni iterazione nel tuo codice mentre la mia ha 1,64*2+3 = 5,3 volte. Certo, la situazione è strana, dobbiamo scoprire qual è esattamente la ragione. Hai un sacco di operazioni bitwise che vengono eseguite lì in aggiunta...
1. Ci rendiamo conto che nelle vostre funzioni il problema non è risolto ma solo mascherato, non perderò peso, stringerò solo di più la cintura.
2. Nella nostra variante e in quella di Alexey è lo scenario peggiore, mentre in molte altre situazioni la velocità sarà quasi al livello di rand(), mentre si ha un tempo costante.
Vi siete mai chiesti perché rand() genera numeri in un intervallo così stretto? Questo è un generatore pseudo-casuale, quindi è periodico, quindi generando un mucchio di numeri casuali in posti dove non è necessario, con successivo scarto di essi, la sua qualità si sta deteriorando (si ripeterà prima).
4. Alcune persone estraggono dati casuali in modo più complicato. Io, per esempio, lo strappo dalla rete, qualcuno potrebbe anche comprarlo. Perché dovrei voler sprecare dati faticosamente conquistati per poi scartarli senza mezzi termini (generare ulong, scrivere un algoritmo adeguato non è la nostra strada, dopo tutto)?
La tua versione differisce dalla mia in quanto chiama sempre 5 rand() mentre la mia ha una media di 1,64 volte a 20 000 range e 1 volta a 256 range. Complessivamente la tua rand() è chiamata 25 volte per ogni iterazione, mentre la mia ha 1,64*2+3 = 5,3 volte. Naturalmente, questa situazione è strana, dobbiamo scoprire qual è esattamente la ragione. Perché hai un sacco di operazioni bitwise che vengono eseguite lì in aggiunta...
I bit sono le operazioni più economiche. Quasi gratis.
Ma nel complesso sono d'accordo. Non capisco neanche io perché... Forse sono le meraviglie dell'ottimizzazione. Anche se ciò che può essere ottimizzato lì...
I bit sono le operazioni più economiche. Quasi gratis.
Ma nel complesso sono d'accordo. Non capisco neanche io perché... Forse sono le meraviglie dell'ottimizzazione. Anche se quello che c'è da ottimizzare...
1. Ci rendiamo conto che nelle vostre funzioni il problema non è risolto ma solo mascherato, non perderò peso, stringerò solo di più la cintura.
2. Nella nostra versione e in quella di Alexey è lo scenario peggiore, mentre in molte altre situazioni la velocità sarà quasi al livello di rand(), mentre si ha un tempo costante.
Vi siete mai chiesti perché rand() genera numeri in un intervallo così stretto? Questo è un generatore pseudo-casuale, quindi è periodico, quindi generando un mucchio di numeri casuali in posti dove non è necessario, con successivo scarto di essi, la sua qualità si sta deteriorando (si ripeterà prima).
4. Alcune persone estraggono dati casuali in modo più complicato. Io, per esempio, lo strappo dalla rete, qualcuno potrebbe anche comprarlo. Ecco perché dovrei sprecare dati faticosamente guadagnati per poi scartarli stupidamente (generando ulong, scrivendo un algoritmo adeguato non è la nostra strada, dopo tutto)?
Beh, questo è da nerd.
Per riprodurre la situazione, quando questo problema sarà avvertibile almeno dello 0,1%, è necessario operare con intervalli superiori ai seguenti valori:
Hai mai usato questi intervalli? Allora perché hai inserito questi controlli e cicli?
Il meglio è nemico del bene.
Personalmente, i miei intervalli digenerazione casuale in pratica sono limitati a 2000, 4000 al massimo. rand() funziona abbastanza bene per questo scopo.
Inserire una tale opzione nel mio codice:
Così non noterete la "slealtà" della funzione rand() (come era con rand()%20000) e i punti saranno situati visivamente in modo uniforme, quindi è la funzione più veloce ed efficiente.
Non per niente gli sviluppatori del processore hanno limitato rand() a 2^15=32768. Non sono persone stupide. Questo copre il 99% dei problemi pratici.
E per gli amanti delle idee "estreme" c'è un'opzione più che sufficiente:
Personalmente, le mie gamme digenerazione di numeri casuali in pratica sono limitate a 2000, massimo 4000. Per questo, rand() funziona abbastanza bene.
Inserire una tale variante nel mio codice:
e non noterete la "slealtà" della funzione rand() (come era con rand()%20000) e i punti saranno visivamente uniformi, quindi è abbastanza funzionante e il più veloce.
Sei il benvenuto a usarlo, non mi dispiace. Tanto più quando il lato destro di % è un multiplo di RAND_MAX+1 (256 o 1024).
E c'è una variante più che sufficiente per chi ama le idee "fuori dai limiti":
Cosa c'entrano gli sviluppatori di processori? Il generatore è implementato via software. L'unico requisito è RAND_MAX >= 32767 e un periodo di almeno 2^32. Quindi il µl ha un oscillatore molto rado ai "minimi".
E i più lungimiranti si faranno una giusta rand() (se non c'è molteplicità), questo è persino raccomandato nei libri di riferimento.