Libreria di classi generiche - bug, descrizione, domande, caratteristiche d'uso e suggerimenti - pagina 4
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
Non stai capendo il contesto. Se vai in giro in vari thread e asserisci sciocchezze senza prove, allora sì, questo è un colpo dritto al ban. Se siete disposti a sostenere le vostre affermazioni con il codice sorgente, siete i benvenuti. Ecco perché Vladimir ti ha dato un avvertimento, perché lui stesso ama il codice sorgente e a volte lo richiede. Guarda i suoi stessi thread per un esempio.
Abbastanza giusto. Se si ottiene il codice di Peter sarà molto bello confrontare le sue prestazioni.
L'ho guardato. Tutto è scritto correttamente. Come vi è già stato detto, la ricerca degli elementi nel dizionario si fa in tempo medio O(1), cioè istantaneamente.
Questo è ciò che suona illogico. Tra migliaia di ordini, sono necessari al massimo 10 controlli. Ma certamente non uno in media. C'è sempre una dipendenza del tempo medio di ricerca dal numero di elementi.
No. O(n) si ottiene a causa di collisioni hash in casi molto rari. Queste sono stime di complessità per l'algoritmo ottimale. Il numero di collisioni è legato all'overhead della memoria
Nel solito caso non c'è essenzialmente bisogno di cercare, perché calcolando l'hash conosciamo già la posizione dell'elemento di cui abbiamo bisogno.
Per quanto mi ricordo, la scelta ottimale della dimensione del dizionario hash è il numero di elementi attesi al quadrato.
Un chiaro esempio di collisioni è il paradosso del compleanno.
https://ru.wikipedia.org/wiki/
Nel caso normale non c'è essenzialmente bisogno di cercare, perché calcolando l'hash si conosce essenzialmente già la posizione dell'elemento in questione.
Non sembra plausibile. Ma aspetterò gli esempi, poi vedrò le viscere dell'implementazione.
Da un lato è bello e dall'altro ricordiamo che MQL ha un sacco di cose che sono assenti in confronto ad altri linguaggi: né eredità multipla, foreach, yeild return, lamb, ...
È chiaro che IEnumerable è fuori questione.
Quindi come possiamo gestire i contenitori C# senza IEnumerable?
Abbiamo ancora i vecchi algoritmi C++ e usiamo le interfacce invece dei puntatori alle funzioni.
Alla fine otteniamo un miscuglio di C# e C++.
Il guazzabuglio di nomi è proprio a causa dei nomi errati che confondono le cose.
Se fossero C++, tutto sarebbe chiaro.
PS E perché questa eredità multipla è assente? Non posso scriverla così in mql5?
Per quanto ho capito, non è un problema.
Ecco perché ci ritroviamo con il C/C++. Se facciamo nomi normali. :)
Esattamente giusto. Se c'è un codice di Peter, sarebbe molto bello confrontare le prestazioni.
Sono sempre disposto a parlare in un linguaggio in codice. L'autore potrebbe semplicemente offrirmi una prova e andrei dritto al punto.
Lasciate che l'autore fornisca il compito e confronteremo le nostre soluzioni per efficienza.
L'argomento è fisso. Si può vedere così:
e puoi vedere immediatamente che l'argomento è appuntato:
Non sembra plausibile. Ma aspetterò gli esempi, poi vedrò le viscere dell'implementazione.
Gli hash sono in media O(1) se la dimensione del dizionario al numero di elementi previsti lo permette.
E poi dipende dalle implementazioni di gestione delle collisioni, potrebbe essere attraverso una lista, potrebbe anche essere un sub-hedge....
Un primo esempio di collisione è il paradosso del compleanno.
L'ho letto sul wiki. Il caso in cui non si capisce affatto la logica del ragionamento intuitivo.
L'argomento è fisso. Si può vedere così:
e puoi vedere immediatamente che l'argomento è appuntato:
Grazie. Cercheremo di rendere questo thread interessante. Vedo già la richiesta del tema:))