L'apprendimento automatico nel trading: teoria, modelli, pratica e algo-trading - pagina 297
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
apply(embed(pattern, length(signal)), 1, cor, y = signal, method = 'pearson')
Grazie! Mi chiedo quanto R conti così. Ho misurato l'algoritmo della Bibbia con una lunghezza del segnale di 1.000.000 e un modello di 100.000 - 1 secondo.
Un milione di volte più veloce! E allora? I sistemi di trading misurano come i processori?
Un milione di volte più veloce! E allora? I sistemi di trading sono misurati come i processori?
Hai una specie di complesso.
No, non un complesso.
μl e R sono sistemi completamente diversi e non sovrapponibili. E cosa c'è da confrontare? E non sei l'unico!
μl e R sono sistemi completamente diversi e non sovrapponibili. E cosa c'è da confrontare? E non sei l'unico!
Ero interessato solo alla velocità di realizzazione di un compito statistico non raro in nessuna delle lingue.
R è il linguaggio statistico più popolare e ci sono molti utenti. Ecco perché ho messo qui la questione del confronto.
È interessante l'algoritmo di implementazione e, di conseguenza, la sua efficienza. Non importa in che lingua è scritto.
Ero solo interessato alla velocità di implementazione di un compito statistico non raro in uno qualsiasi dei linguaggi.
R è il linguaggio statistico più popolare e molte persone qui lo conoscono. Ecco perché qui si pone la questione del confronto.
È interessante l'algoritmo di implementazione e, di conseguenza, la sua efficienza. Non importa in che lingua è scritto.
MT è un terminale di trading. Quindi io, qui su questo sito e in questo thread, sto discutendo lo sviluppo di TS. Ma troviamo sempre persone che discutono di alcuni trucchi di programmazione che non hanno praticamente alcun effetto sui risultati commerciali. La funzione di correlazione stessa è utile in altri algoritmi.
Questa funzione può essere usata nei blocchi di decisione di trading (almeno io la uso) ma la sua velocità di esecuzione non gioca alcun ruolo, perché il tempo principale per il calcolo di un segnale di trading è determinato da altri algoritmi computazionalmente complessi che non sono affatto presenti in mql.
Questo è allo stadio dell'esecuzione.
Se consideriamo la fase di sviluppo del TS, R è principalmente superiore a µl, poiché è un interprete, che è molto utile nella fase in cui l'algoritmo non è del tutto chiaro e abbiamo bisogno di provare molte varianti, per esempio, per confrontare le correlazioni di coppie di valute. Su R il tempo di controllare la correlazione è un colpo sulla tastiera, con un paio di righe, tra cui una formazione molto comoda di vettori iniziali.
Questo era il punto che stavo facendo, che non ha senso confrontare la velocità di esecuzione di queste funzioni e in generale qualsiasi altra funzione implementata su mcl e R.
PS.
Ma la vostra biblioteca mi ha salvato dallo studio di mcl5, grazie per questo.
MT è un terminale di trading. Di conseguenza, io, qui su questo sito e in questo thread, discuto lo sviluppo della ST. Ma troviamo sempre persone che discutono di alcuni trucchi di programmazione che non hanno praticamente alcun effetto sui risultati commerciali. In effetti la tua domanda è la stessa perché la funzione di correlazione stessa ha senso in altri algoritmi.
In precedenza, alcune idee non potevano essere testate da TC, poiché era ostacolato dalle basse prestazioni di alcuni algoritmi. In questo caso è esattamente quello che è successo - un algoritmo alternativo ha permesso all'ottimizzatore di esplorare un'idea che è vecchia come il mondo, ma che prima non poteva essere calcolata in un tempo ragionevole.
Quando si devono calcolare centinaia di miliardi di Pearson QC in modelli di poche migliaia di lunghezza, la bassa velocità di un compito apparentemente semplice diventa un collo di bottiglia insormontabile. Si potrebbe iniziare a dire che se un problema appare troppo pesante dal punto di vista computazionale, è un problema mal formulato e poco compreso. Forse è così. Ma quel che è fatto è fatto. Ed è sempre interessante vedere come gli altri implementano queste cose.
È meglio spendere un po' più di tempo nello sviluppo, ma poi calcolare sempre velocemente, o sviluppare velocemente e poi sopportare sempre un calcolo lento?
Se R è veloce da sviluppare ma lento da calcolare, allora dove si calcola? Per sviluppare rapidamente una supercar che è lenta? Non hai bisogno di una tale supercar.
Ero solo interessato alla velocità di implementazione di un compito statistico non raro in uno qualsiasi dei linguaggi.
R è il linguaggio statistico più popolare e molte persone qui lo conoscono. Ecco perché qui si pone la questione del confronto.
È interessante l'algoritmo di implementazione e, di conseguenza, la sua efficienza. Non importa in che lingua è scritto.
Beh, su un segnale di lunghezza 1000000 e un modello di lunghezza 100000 quell'implementazione è improbabile che conti in un tempo ragionevole, perché richiederebbe la creazione di una matrice temporale 900001x100000 :D Ma ci sono voluti meno di 30 secondi per scriverla, e fino a una certa dimensione del compito sarà abbastanza applicabile. Potremmo fare la stessa cosa con fft/convolve, nel qual caso avremmo bisogno di scrivere più codice, ma sarebbe altrettanto veloce del codice C.
In R è molto conveniente fare prototipi di modelli complessi - questo è il suo lato forte. La performance del codice è una questione di capacità ed esperienza:
1. Alcuni costrutti e tipi di dati R funzionano più velocemente di altri (tipi mutabili vs immutabili (lista vs ambiente), for vs lapply/sapply/etc., S4 vs R6).
2. La facilità di parallelismo in R per alcuni problemi permette di ottenere una soluzione di codice lento più velocemente di quanto ci vorrebbe per scrivere codice veloce in un altro linguaggio + calcolo.
3. le singole operazioni nella lingua sono fatte universalmente, ma in modo inefficiente. Se si implementano funzioni piccole ma computazionalmente pesanti in C++, si possono ottenere risultati enormi senza ridurre la velocità di sviluppo tanto quanto nel caso in cui si scriva l'intero codice in un linguaggio simile al C. Per esempio, sommare elementi della matrice su righe o colonne in R può essere da 4 a 15 volte più veloce di rowSum/colSum/apply(, 1, sum)/apply(, 2, sum).
Beh, su un segnale di lunghezza 1000000 e un modello di lunghezza 100000 quell'implementazione difficilmente può essere calcolata in un tempo ragionevole, poiché richiederebbe la creazione di una matrice temporale 900001x100000 :D Ma ci sono voluti meno di 30 secondi per scriverla, e fino a una certa dimensione del compito sarà abbastanza applicabile. Possiamo implementare la stessa cosa con fft/convolve, nel qual caso avremmo bisogno di scrivere più codice, ma la velocità di esecuzione non sarebbe troppo inferiore al codice C.
R è molto bravo a prototipare modelli complessi - questa è la sua forza. La velocità del codice è una questione di abilità ed esperienza:
1. Alcuni costrutti e tipi di dati R sono più veloci di altri (tipi mutabili vs immutabili (lista vs ambiente), for vs lapply/sapply/etc., S4 vs R6).
2. La facilità di parallelismo in R per alcuni problemi permette di ottenere una soluzione di codice lento più velocemente di quanto ci vorrebbe per scrivere codice veloce in un altro linguaggio + calcolo.
3. le singole operazioni nella lingua sono fatte universalmente, ma in modo inefficiente. Se si implementano funzioni piccole ma computazionalmente pesanti in C++, si possono ottenere risultati enormi senza ridurre la velocità di sviluppo tanto quanto nel caso in cui si scriva l'intero codice in un linguaggio simile al C. Per esempio, sommare elementi della matrice su righe o colonne in R può essere da 4 a 15 volte più veloce di rowSum/colSum/apply(, 1, sum)/apply(, 2, sum).