L'apprendimento automatico nel trading: teoria, modelli, pratica e algo-trading - pagina 1590
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
Ho letto questo articolo circa 5 anni fa, è interessante, ma non ci sono molte informazioni aggiuntive, l'autore sta facendo qualcosa con OHLC per ottenere una metrica di volatilità più "conveniente", non è nuovo in linea di principio, nel classico Dacorogna "An introduction to high-frequency finance" nel secolo scorso si raccomandava di prendere i rendimenti medi assoluti, non i valori RMS come misura di volatilità. Anche la prevedibilità della volatilità è un fatto noto: dipende da due fattori, la stagionalità e l'inerzia, che rappresenta il 95% della sua influenza. Ma anche se allineiamo i (log)rendimenti in base alla volatilità non darà nulla, abbiamo bisogno di un segno per il trading, e non influenza la distribuzione in alcun modo.
Per esempio, se prendete un rumore gaussiano, ovviamente non potete prevedere i seguenti usando i campioni precedenti a prescindere dalla stazionarietà, ma se ordinate quella serie, per esempio, che non cambierà la distribuzione ma la renderà completamente prevedibile, allora potete giocare con la volatilità dinamica in un ampio intervallo e renderla non stazionaria, ma ancora facilmente prevedibile.
C'è un certo senso nel fare tutto questo non su un solo timeframe, ma su qualche segmento di essi, confrontando il quadro risultante con quello che dovrebbe essere su una SB gaussiana con varianza simile.
Se è necessario essere rigorosi, possiamo considerare che stiamo parlando della mancanza di stazionarietà nel senso ampio dei logaritmi dei rendimenti, per esempio.
https://github.com/BlackArbsCEO/mixture_model_trading_public/blob/master/notebooks/current_public_notebooks/03_Are_Gaussian_Mixture_Components_More_Stationary_2019-01-01.ipynb
Ha un certo senso fare tutto questo non su un solo timeframe, ma su un certo segmento di essi, confrontando il quadro risultante con quello che dovrebbe essere su una SB gaussiana con varianza simile.
Per quanto riguarda la distribuzione dei rimpatriati, è molto importante che più alto è il lasso di tempo, più la distribuzione diventa gaussiana, per la banale ragione della media (ricordiamo tutti che l'aggregazione di distribuzioni non normali dà una distribuzione normale). I veri eventi "casuali" nel mercato sono solo cambiamenti di un best (askbid), piazzando/disegnando un ordine o un accordo; l'aggregazione di tick anche in un minuto cambia la distribuzione, rendendola più vicina alla distribuzione gaussiana (per rendere la distribuzione gaussiana da quella uniforme ci vogliono 12 iterazioni), la vera distribuzione del mercato è solo la distribuzione dei tick, e non è affatto normale.
Per quanto riguarda la distribuzione dei rimpatriati, è molto importante che più alto è il lasso di tempo, più la distribuzione diventa gaussiana, per la ragione banale della media (ricordiamo tutti che l'aggregazione di distribuzioni non normali dà una distribuzione normale). I veri eventi "casuali" nel mercato sono solo cambiamenti di un best (askbid), piazzando/traendo un ordine o eseguendo un trade, l'aggregazione di tick anche in un minuto cambia la distribuzione rendendola più vicina alla distribuzione gaussiana (12 iterazioni sono sufficienti per trasformare la distribuzione uniforme in quella gaussiana), la vera distribuzione del mercato è solo quella dei tick, e non è affatto normale.
Per le valute anche non è reale. Più precisamente, non è affatto reale, e non è affatto "normale" (nemmeno in termini di distribuzioni).
Perché non c'è un centro. Non c'è un'unica fonte di zecche e nessuna garanzia che arrivino all'utente. Non solo il "flusso ipotetico di tick" di un particolare server è il prodotto dell'aggregazione di altri server, ma questo flusso è anche diluito sia dal server che dal terminale per ragioni tecniche.
Le caratteristiche statiche delle zecche dipendono dal DC specifico, dai suoi pari e dal loro software.
Per quanto riguarda la distribuzione dei rimpatriati, è molto importante che più alto è il lasso di tempo, più la distribuzione diventa gaussiana, per la ragione banale della media (ricordiamo tutti che l'aggregazione di distribuzioni non normali dà una distribuzione normale). I veri eventi "casuali" nel mercato sono solo cambiamenti di un best (askbid), piazzando/traendo un ordine o eseguendo un trade; l'aggregazione di tick anche in un minuto cambia la distribuzione rendendola più vicina alla distribuzione gaussiana (per fare una distribuzione gaussiana da una uniforme, sono sufficienti 12 iterazioni), la vera distribuzione del mercato è solo la distribuzione dei tick, e non è affatto normale.
Tuttavia, a livello di tick un modello più corretto è alcune variazioni del processo di Poisson, ad esempio un processo di Poisson composto con una distribuzione discreta di salti e una funzione temporale non costante. Questo, tuttavia, ignora la discrepanza del tempo reale di negoziazione.
La forma dell'istogramma dipende dalle aree che incontriamo (Maxim Dmitrievsky ha scritto poco sopra sulle miscele). A volte risulta anche un istogramma a doppia gobba.
Dato che non so come trasferire un modello completamente markoviano a metac, l'idea è di raggruppare tutte le componenti stagionali in Python, poi addestrare un semplice MOH per prevedere i cluster, testare su un campione di prova. E trasferirlo al terminale. Questa sarà la bomba numero 3.
Ci si aspetta che ogni cluster abbia una varianza e una matroide costante.
Dato che non so come trasferire un modello completamente markoviano a metac, l'idea è di raggruppare tutte le componenti stagionali in Python, poi addestrare un semplice MOH per prevedere i cluster, testare su un campione di prova. E trasferirlo al terminale. Questa sarà la bomba numero 3.
Ci si aspetta che ogni cluster abbia una varianza e una matroide costante.
Dato che non so come trasferire un modello completamente markoviano a metac, l'idea è di raggruppare tutte le componenti stagionali in Python, poi addestrare un semplice MOH per prevedere i cluster, testare su un campione di prova. E trasferirlo al terminale. Questa sarà la bomba numero 3.
Ci si aspetta che ogni cluster abbia una varianza e una matroide costante.
Ancora, a livello di tick un modello più corretto è una qualche variazione del processo di Poisson, per esempio il processo di Poisson composto con distribuzione discreta di salti e intensità variabile (NON funzione di tempo costante)).
Non funzionerà per molte ragioni, è stato studiato da molto tempo e non si tratta nemmeno del filtraggio delle zecche da parte del server DC
questo è quello che so dove cercarehttps://www.mql5.com/ru/forum/102066/page9#comment_2968124 in questa foto dove la freccia è un outlier
Questi tick ci saranno sempre, è così che funziona il mercato - perché si verificano è un'altra questione
e se si segue la tua ipotesi sui salti di tick, si considerano questi picchi, ma questi tick non formano la direzione di ulteriori movimenti, al massimo si verificano sul alto/basso di una barra
Non sono riuscito a trovare screenshot dell'indicatore tick di Prival, è molto bravo a rappresentare questi picchi - così non devi indovinare da dove viene il tick. Una possibilità è che MM spesso mescola i dati asc/bid con un ritardo temporale, ma questa è una citazione reale! )))
Bomba #5 è di tendenza con tempi specifici, ripetuti a intervalli regolari. Ma devi passare anche per il numero 4
È già nella bomba numero 2 :)