L'apprendimento automatico nel trading: teoria, modelli, pratica e algo-trading - pagina 2587
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
Aggiunto un tale predittore di distanza dalla barra corrente oggi. Puoi avere un numero o solo un'ora. Ho preso tempo.
Tutto è più o meno chiaro con il tempo ciclico. Non capisco molto del tempo lineare - sarà diverso per il vassoio e per l'avanti? O la "barra attuale" è presa indipendentemente per ogni campione?
Ho avuto un'idea per prendere una regressione logistica lineare ordinaria e vedere la significatività della differenza dal coefficiente zero al tempo (o a qualche funzione del tempo) o confrontare questa significatività con la significatività per altri predittori.
Il tempo ciclico è più o meno chiaro. Non è molto chiaro con il tempo lineare - sarà diverso per un vassoio e un avanti? O la "barra attuale" è presa indipendentemente per ogni campione?
Ho avuto un'idea per prendere semplicemente una regressione logistica lineare ordinaria e vedere la significatività di una differenza dal coefficiente zero al tempo (o a qualche funzione del tempo) o confrontare questa significatività con la significatività per altri predittori.
Un'onda sinusoidale è per il tempo ciclico come l'ora del giorno o il giorno della settimana. E lì originariamente (Aleksey Vyazmikin) parlava di tempo lineare ordinario per cercare di cogliere l'effetto della non stazionarietà sotto forma di decadimento del modello. A mio parere, per risolvere questi problemi si dovrebbero usare modelli semplici e facilmente interpretabili. I modelli complessi sono per scopi pratici, quelli semplici per analisi preliminari.
Tuttavia, ci sono dubbi sull'utilità pratica di tale manipolazione in questo caso particolare. Molto probabilmente, i nostri modelli non cambiano uniformemente nel tempo, ma ciclicamente (ma senza periodicità).
Un'onda sinusoidale è per il tempo ciclico come l'ora del giorno o il giorno della settimana. E lì originariamente (Aleksey Vyazmikin) parlava di tempo lineare ordinario per cercare di cogliere l'effetto della non stazionarietà sotto forma di decadimento del modello. A mio parere, per risolvere questi problemi si dovrebbero usare modelli semplici e facilmente interpretabili. I modelli complessi sono per scopi pratici, quelli semplici per analisi preliminari.
Tuttavia, ci sono dubbi sull'utilità pratica di tale manipolazione in questo caso particolare. Molto probabilmente le nostre regolarità cambiano nel tempo non uniformemente, ma ciclicamente (ma senza periodicità).
In generale, l'idea di alimentare il tempo lineare è una cattiva idea. A proposito, sì: nel vassoio è diverso in ogni linea e in avanti si analizza solo 1 linea alla volta, cioè il tempo sarà sempre attuale (che non era nel vassoio), e il numero sempre = 0 (e nel vassoio da 0 a 5000). Cioè non si può fornire né il tempo né il numero del vassoio. Questo è ciò che il test ha dimostrato.
Anche se proverò di nuovo con il numero... Perché il numero zero sarà incluso in quella parte dell'albero che < una certa divisione (per esempio <5000) Cioè una parte dell'albero per l'inoltro sarà usata. Non tutto. Qualcosa che ho deciso di prendere tempo per il test, per errore.
Ma come fare uno split per numero era ad una distanza ottimale per l'avanti?
Provato. Il modello con 5000 barre di storia da imparare, dopo aver aggiunto il numero di linea come caratteristica, per Buy è migliorato, per Sell per certi versi peggio, per certi versi meglio.
Allo stesso tempo, se insegniamo su 10000 barre, entrambi i modelli diventano in perdita. Cioè il compito principale di aggiungere il numero di linea per la determinazione automatica della lunghezza della storia necessaria non è stato adempiuto.
Finora, dobbiamo solo ottimizzare/selezionare manualmente la lunghezza della storia per l'apprendimento.
Sembra che l'idea di base dell'uso di metriche di trader personalizzate sia che siano usate nella fase di selezione del modello. Nella fase di formazione, vengono utilizzate le metriche standard. Probabilmente, è qualcosa come quello che Maxim Dmitrievsky ha scritto prima su questo argomento.
Un piccolo articolo per illustrare l'approccio.
Apparentemente, l'idea principale di utilizzare le metriche del trader personalizzato è che vengono utilizzate nella fase di selezione del modello.
Anche se ci sono alcune idee di utilizzare metriche personalizzate nella fase di formazione. Allo stesso tempo non sono del tutto simili a quelle dei commercianti, ma piuttosto sono versioni modificate di quelle standard per MO.
Forse le metriche dei commercianti portano a una scarsa condizionalità. Questo ricorda, per esempio, l'uso della cross-entropia al posto del tasso di errore originale di interesse (quest'ultimo è detto essere poco sensibile).
È necessario ridurre in qualche modo le lacune teoriche e pratiche tra la formazione in IR e l'ottimizzazione nel tester.
Anche se ci sono alcune idee di utilizzo di metriche personalizzate già in fase di formazione. Tuttavia, non sono esattamente come le metriche dei commercianti, ma piuttosto varianti modificate delle metriche MOE standard.
Forse le metriche dei commercianti portano a una scarsa condizionalità. Assomiglia, per esempio, all'uso dell'entropia incrociata al posto della frequenza di errore originale di interesse( si dice della scarsa sensibilità di quest'ultima).
Dobbiamo in qualche modo ridurre le lacune teoriche e pratiche tra la formazione in MO e l'ottimizzazione nel tester.
Quando facevo modelli con TP/SL la precisione era assoluta. Nel modello e nel tester, i trade sono stati aperti sulle stesse barre e chiusi con lo stesso TP/SL. Ma la redditività era circa 0.
Stavo testando sulla base dei prezzi aperti. Ma c'è un problema con loro... Lo spread minimo è usato nella barra.
Cioè, una parte degli ordini e dei TP/SL nel tester si innescheranno a
ASK HIGH = BID HIGH + spread minimo.
Quelli che verrebbero attivati nel commercio reale non funzioneranno
ASK HIGH (reale) = BID HIGH + Spread calcolato dalla ASK massima
Un paio di volte ho suggerito agli sviluppatori di salvare in barre non lo spread minimo, ma
Spread = ASK HIGH - BID HIGH.
Con un tale spread, il test dei prezzi aperti sarebbe più vicino al test dei tick reali.
Per esempio, spread minimo su una barra = 0,00002, mentre Spread = ASK HIGH - BID HIGH = 0,00020. Cioè nella realtà il prezzo ASK era più alto di quello del tester di 0,00018. Dove potrebbero essere avvenute le aperture/chiusure commerciali.
Ma non c'è stata alcuna risposta da MetaQuotes (in russo)
PS: Per essere più precisi, si dovrebbe calcolare anche lo spread Low Ask.