L'apprendimento automatico nel trading: teoria, modelli, pratica e algo-trading - pagina 298
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
È meglio spendere un po' più di tempo nello sviluppo e poi calcolare sempre velocemente, o sviluppare velocemente e poi sopportare sempre dei calcoli lenti?
Se sviluppate velocemente in R ma siete lenti a calcolare, dove volete fare i calcoli? Velocemente si sviluppa una supercar che è lenta da guidare? Non hai bisogno di una tale supercar.
Nei compiti di ricerca è la velocità di sviluppo che viene in primo piano. Invece di una persona che scrive codice superveloce ma testa 1 ipotesi al giorno, una persona che scrive codice lento ed esegue calcoli tutta la notte, ma ha 20 ipotesi testate entro il giorno successivo, viene facilmente assunta.
Per la produzione-implementazione del modello è più facile assumere un'altra persona con un piccolo stipendio, che riscriva i modelli più promettenti nel linguaggio più veloce possibile. Ci sono molti programmatori e la concorrenza è alta, ma i ricercatori che possono inventare qualcosa di nuovo sono difficili da trovare :P
È una pratica comune. Cerca lavori come ricercatore quantitativo e sviluppatore quantitativo. I primi di solito hanno bisogno di R/Python, i secondi di C++/Java.
Nei compiti di ricerca, è la velocità di sviluppo che viene in primo piano. Invece di una persona che scrive codice superveloce, ma controlla 1 ipotesi al giorno, una persona che scrive codice lento e fa calcoli tutta la notte, ma il giorno dopo ha 20 ipotesi controllate.
Per la produzione-implementazione del modello, è più facile assumere un'altra persona per un piccolo stipendio per riscrivere i modelli più promettenti in un linguaggio veloce. Ci sono molti programmatori, e la competizione è alta; ma i ricercatori che possono inventare qualcosa di nuovo sono difficili da trovare :P
È una pratica comune. Cerca lavori come ricercatore quantitativo e sviluppatore quantitativo. I primi di solito devono conoscere R/Python, i secondi di solito devono conoscere C++/Java.
Non sarebbe più facile usare librerie C++ pronte e veloci invece di usare le stesse ma lente in R per uno "sviluppo veloce"? Tu, e molti altri qui, fate costantemente una sostituzione di nozioni. Allo stesso modo, si può "sviluppare rapidamente" in un ambiente simile al C. O non hai bisogno di conoscenze adeguate in data mining e statistica per lavorare in R? Allo stesso modo avete bisogno della conoscenza per sviluppare in C. Allora perché fare un doppio lavoro?
E non so di che tipo di "pratica normale" parli, ma io sono abituato a fare bene una volta e una volta sola.
Durante la mia pratica ingegneristica ho visto spesso persone che per qualche motivo pensavano che se avessero usato un software super-duper-friendly per lo sviluppo avrebbero sicuramente fatto bene... Ma non riuscivano a capire una cosa: hanno bisogno di un'altra cosa perché tutto funzioni bene: il grasso nella loro testa.
Non è più facile usare librerie C++ già pronte e veloci invece di usare le stesse ma lente in R per uno "sviluppo veloce"? Tu, e molti altri qui, fate costantemente una sostituzione di nozioni. Allo stesso modo, si può "sviluppare rapidamente" in un ambiente simile al C.
La scelta del linguaggio è un tuo diritto e affare personale. Riguardo alle librerie - ahimè, per qualsiasi algoritmo moderno o insolito, devi implementare tutto da solo. Per esempio, per calcolare la "varianza bipotenza" (cosa significa? :D) non ho trovato librerie.
O non c'è bisogno di conoscenze adeguate in data mining e statistica per lavorare in R?
Non pretendo questo e non sostengo questa opinione.
E non so di quale "pratica comune" tu stia parlando, ma io sono abituato a fare bene una volta e una volta sola.
Durante la mia pratica ingegneristica, ho visto spesso persone che, per qualche ragione, pensavano che se avessero usato un software super-duper-friendly per lo sviluppo, avrebbero sicuramente fatto bene... Ma non riuscivano a capire una cosa - avevano bisogno di qualcos'altro perché tutto fosse buono: il grasso nella loro testa.
La mia pratica in alcuni progetti con ## anni-uomo di complessità, dove il 95% del codice è scritto in R, mostra che diversi strumenti sono buoni per compiti diversi, a volte anche lenti, purché siano usati per prototipi e non per la produzione. L'utilizzo di diversi strumenti in diverse fasi di sviluppo è una pratica comune nell'industria dello sviluppo ed è confermata dalle richieste di specialisti per diversi lavori. I progetti che ho menzionato sarebbero diventati molto più complessi se fossero stati implementati in un linguaggio simile al C, anche da soldati universali che sanno e possono fare tutto e scrivere subito la soluzione al problema, senza alcuna fase di ricerca.
Perciò mi congedo.
Non è più facile usare librerie C++ già pronte e veloci invece di usare le stesse ma lente in R per uno "sviluppo veloce"?
Quando si discute di R, ho sempre puntato su una valutazione completa e sistematica di questo "sistema di grafica e statistica". il linguaggio algoritmico stesso non è affatto menzionato nel titolo.
Un confronto frontale delle prestazioni del codice in R e come sopra del codice in µl, o un altro linguaggio di programmazione, su un esempio specifico e locale è completamente NON corretto, poiché TC non consiste mai come discusso sopra di una funzione di correlazione, ma è sempre un grande insieme composto da codice e chiamate di funzione. Dato che R ha un enorme insieme di funzioni, il codice di solito ha un piccolo numero di linee (1000 linee sono tante), ma un contenuto molto capiente.
Il programma stesso, che risolve qualche problema significativo, può essere approssimativamente diviso in due parti:
Sul punto 1, se si dovessero scrivere quantità significative di codice, allora il problema della velocità può essere molto serio. Ci sono tre modi per superarlo:
Sul punto 2, le prestazioni sono abbastanza diverse e dubito che senza sforzi speciali nello sviluppo abituale di µl-programma possa superare R nelle prestazioni.
Per esempio.
In superficie, le operazioni su vettori e matrici in R sono basilari. Un'espressione della forma a <- b*c viene eseguita dalla libreria Intel. Non ci sono anelli. È disponibile per tutti, non sono richieste conoscenze o sforzi aggiuntivi. Quando si sviluppa un programma μl, molto probabilmente si useranno i cicli, sebbene sia anche possibile fare riferimento alla stessa libreria (se il programma non è per il mercato), ma è richiesto un livello piuttosto alto di conoscenza e sforzo per ottenere lo stesso risultato.
Ma non è tutto.
Se ci occupiamo di algoritmi computazionalmente pesanti, e questi sono appelli a funzioni R, lo sviluppatore stesso, di fronte al problema delle prestazioni, si è preoccupato di questo problema e di solito lo ha risolto in fase di sviluppo. Questo viene solitamente risolto scrivendo codice C o facendo riferimento a librerie C o Fortran. Inoltre, tali algoritmi hanno tra i loro parametri la possibilità di specificare l'uso di molti core. Uno sviluppatore in R ottiene tutto questo automaticamente senza sforzi. Ci si può concentrare completamente sull'essenza di TC, non sulla tecnica di attuazione. È dubbio che lo sviluppatore di μl-programma possa superare lo sviluppatore di funzioni in R per la ragione banale - è necessario lavorare specificamente sulle prestazioni, ma non sull'essenza di TC.
Da tutto ciò che è stato scritto segue che un confronto corretto delle prestazioni sarebbe quello di scrivere codice TC reale su µl e lo stesso codice su µl+R (non ci sono ordini di compravendita in R) e confrontare. Ma nel suo pieno splendore - ne abbiamo bisogno?
Qualcuno ha provato a lavorare con i diagrammi di ricorrenza? Potete leggerlo quihttps://habrahabr.ru/post/145805/, in particolare per sostituire i MO al posto dei BP grezzi? potrebbe funzionare come opzione
e altro da leggerehttp://geo.phys.spbu.ru/Problems_of_geophysics/2005/20_Zolotova_38_2005.pdf
Un'idea per chi può attuarla. La visione artificiale confronta queste trame alla ricerca di una corrispondenza del modello. Come sostituto di un'inutile correlazione
Un'idea per coloro che possono implementare questo. Confronto a macchina di queste trame alla ricerca della corrispondenza dei modelli. Come sostituto di un'inutile correlazione.
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 altri implementano cose simili.
E se lo implementate anche sulla GPU, sarete davvero preziosi))
Senza ponzi si può trovare il modello più frequente. Ma qual è il punto?
Bene per una strategia di pattern, ovviamente ) non necessariamente la più frequente, ci possono essere molte varianti
Non è necessariamente il più frequente per le strategie di pattern, ci possono essere molte varianti.
Questo è quello che non capisco. L'uso dei dati di pattern è utile quando si comprimono i dati con poca perdita di informazioni (vari media). Ma cosa ha a che fare questo con TC?
Il modo più semplice per parlare di questo argomento è usare il modello più frequente come esempio. Non è un compito difficile trovarlo.
Ecco qualche indovinello (schema) che si verifica più spesso. Il suo criterio di selezione non è così importante in questo momento. Che l'enigma sia lì. Come usarlo per il trading?
Dire che se una storia più esterna coincide con una zagulina nel primo 80%, allora i prezzi successivi seguiranno lo stesso schema del restante 20% della zagulina è una sciocchezza.
Questo è quello che non capisco. L'uso dei dati di pattern è utile quando si comprimono i dati con poca perdita di informazioni (vari media). Ma cosa ha a che fare questo con TC?
Il modo più semplice per parlare di questo argomento è usare il modello più frequente come esempio. Non è un compito difficile trovarlo.
Ecco qualche indovinello (schema) che si verifica più spesso. Il suo criterio di selezione non è così importante in questo momento. Che l'enigma sia lì. Come usarlo per il trading?
Dire che se una storia più esterna coincide con una zagulina nel primo 80%, allora i prezzi seguenti andranno allo stesso modo del restante 20% della zagulina è una sciocchezza.
Perché pensate che sia una sciocchezza? Se la previsione sarà confermata, sulla stessa storia, in una massa di casi