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
Ora ho un problema. Ho bisogno di rendere efficiente l'ordinamento degli array con grande "costo" della copia degli elementi (cioè elementi di cui sono grandi, strutture "pesanti", oggetti di classe, lunghe stringhe, ecc. Il senso comune suggerisce che dovremmo lasciarli sul posto, ma ordinare invece una sorta di puntatori - indici di celle della loro posizione originale. Ecco la citazione di https://www.mql5.com/ru/forum/6476#comment_178318Оставим finora, con i loro molti compiti attuali, e implementarlo in mql5.
Tutto è già stato rubato prima di noi :)
Fogli di calcolo in MQL5
L'input dovrebbe essere una copia dell'array da ordinare, i commenti dovrebbero essere annotati e il non necessario dovrebbe essere commentato
Tutto è già stato rubato prima di noi :)
Fogli di calcolo in MQL5
L'input dovrebbe essere una copia dell'array da ordinare, i commenti dovrebbero essere annotati e il superfluo commentato.
Sei cattivo! Hai rovinato la canzone... O meglio - ci ha provato. :)
// È chiaro che ci sono buone approssimazioni. Potrei anche aver preso un campione dalla libreria standard. :)
Ci sono degli schemi. E ce ne sono anche di eccellenti. Ma comunque. Qui è importante registrare e fare il debug di tutto fino a una condizione di lavoro di un prodotto utilizzabile separatamente. Inoltre (perché lo sto inviando qui) - il più velocemente possibile. Cioè suggerisco di spremere tutte le prestazioni possibili fino ai centesimi di percentuale inclusi. :)
Questo è il primo. In secondo luogo, per gli oggetti abbiamo bisogno di un numero di array di indici pari al numero di criteri di ordinamento, che nel caso generale possono essere diversi, + (preferibilmente) la funzione di inserimento nell'array indicizzato secondo diversi criteri.
Sei cattivo! Hai rovinato la canzone... O meglio, ci hai provato. :)
// È chiaro che ci sono buone approssimazioni. Potrei anche aver preso un campione dalla libreria standard. :)
Ci sono dei campioni. E anche alcuni grandi. Ma comunque. È importante controllare e fare il debug di tutto fino a una condizione di lavoro di un prodotto utilizzabile separatamente. E (perché lo sto inviando qui) - il più veloce. Cioè suggerisco di spremere tutte le prestazioni possibili fino ai centesimi di percentuale inclusi. :)
Questa è la prima cosa. Secondo - per gli oggetti abbiamo bisogno di un numero di array di indici pari al numero di criteri di ordinamento, che in generale possono essere diversi, + (preferibilmente) la funzione di inserimento nell'array indicizzato secondo diversi criteri.
Stessa risposta Fogli di calcolo in MQL5.
È tutto lì. Sotto un problema concreto, è possibile rifare sotto manipolazione non colonne ma righe, ci sono colonne fatte per è possibile dichiararle come tipi diversi. Se il tipo di tabella è lo stesso, tutto può essere riprodotto.
Fatto un inluder con indici di ordinamento per i tipi di base.
L'ordinamento predefinito è "discendente", per ordinare in senso ascendente, impostare il flag di direzione dell'ordinamento su false.
Risultati del test: // indicizzazione degli array double[], int[], string[]; sequenzialmente: array grezzo, array discendente, array ascendente
Biblioteca e test nel rimorchio.
Metti l'indicizzatore nella cartella "MQL5\Include\Indexes\".
Ecco un esempio di classe per lavorare con OCL. Naturalmente, alcune cose sono incomplete e scomode, ma forse qualcuno lo troverà utile.
Ho rielaborato un po' l'inizializzazione, ora è possibile eseguire calcoli multidimensionali.
Grande argomento!
Proprio ora ho affrontato un problema di ottimizzazione con un algoritmo per trovare un estremo (minimo) di prezzo. Le condizioni sono le seguenti: c'è una barra, n barre a sinistra e a destra della quale sono sotto (sopra) il suo massimo:
n è un valore libero scelto arbitrariamente. Il periodo n è sempre dispari, perché la somma delle due barre a destra e a sinistra sarà sempre un numero pari a cui si aggiunge la barra centrale dell'estremo del prezzo vero e proprio.
Non ho pensato molto alla prima versione dell'algoritmo e ho scritto il codice più ovvio. Ora lo sto scrivendo in C# usando la piattaforma WealthLab, ma penso che si possa facilmente capire l'essenza dell'algoritmo problematico, ecco la parte più problematica di esso:
L'intero problema è nel secondo ciclo. Gestisce simultaneamente i rami sinistro e destro di un potenziale estremo e quindi attraversa solo (N - 1)/2 barre, ma questo non è sufficiente. Le misurazioni mostrano che il tempo impiegato per identificare un estremo in una progressione aritmetica dipende dal periodo N, il che è molto, molto brutto:
Provare attraverso i periodi richiederà il tempo di sommare la progressione aritmetica, e questo è un valore molto grande.
Una possibile soluzione è quella di introdurre una variabile aggiuntiva. Dopo tutto, se un estremo è identificato, è garantito che non c'è nessuna barra alla sua destra per (N - 1)/2 quindi un nuovo estremo può essere identificato a partire da bar: current_bar + (N - 1)/2. Tuttavia, gli estremi devono essere identificati insieme ai minimi e un nuovo minimo può essere trovato prima di current_bar + (N - 1)/2. Sarà quindi necessario dividere la ricerca degli estremi e dei minimi in due passaggi, il che annullerà qualsiasi guadagno di prestazioni. Possiamo facilmente dividere due passaggi in due thread elaborati simultaneamente su due core in C#, ma vorrei trovare l'algoritmo ottimale e ottimizzarlo prima di tutto. Sto aspettando l'aiuto degli esperti.
Beh, questo non è un problema di ottimizzazione.
Provando attraverso i periodi si prende la somma della progressione aritmetica, e questo è un valore molto grande.
Trovare un estremo sembra essere un problema dell'ordine di O(n), dove n è il numero di dati. Come si può rendere questo asintotico peggiore, cioè O(n^2) - non posso nemmeno immaginare. O stai confondendo i termini.
L'algoritmo più semplice è ArraySort(), abbastanza veloce, qualcosa intorno a O(n * ln( n ) ), ma probabilmente è ridondante per questo problema.
Si potrebbe inventare qualcosa di ricorsivo che sarebbe più veloce.
Quanto tempo ci vuole per trovare il minimo e per quante barre? Beh, non credo che per 100 barre si cerchi al massimo un secondo e mezzo.
L'algoritmo più semplice è ArraySort(), l'ordinamento integrato è abbastanza veloce, ma è probabilmente ridondante per questo compito.
Il miglior ordinamento è O(n*log(n)). Esattamente ridondante.
Potremmo inventare qualcosa di ricorsivo che sarebbe più veloce.
Più lento. La ricorsione è il più delle volte un male. Ricorsivo? Questo è probabilmente un caso in cui non importa come lo fai, la velocità sarà circa la stessa.
Per codice:
I cicli per min e max devono essere esplicitamente separati. E uscire immediatamente dal ciclo se fallisce.
In linea di principio, sì. Ma ancora non più di O(n).
OCL aiuterebbe qui. L'asintotica rimarrà la stessa, ovviamente. Ma la velocità potrebbe essere aumentata di cento volte.