Regressione bayesiana - Qualcuno ha fatto un EA usando questo algoritmo? - pagina 45
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
http://www.quantalgos.ru/?p=1898 forse l'autore di questo topic ne beneficerà...
Generatore di numeri pseudocasuali. (PRNG)
Usando il metodo delle coordinate polari suggerito sopra, ho trasformato МТ4 PRNG in PRNG con un valore casuale normalmente distribuito.
Per controllare visivamente la correttezza del codice, ho proiettato i risultati sul grafico dei prezzi.
Questo è ciò che il PRNG di base mostra dopo 1000 chiamate. Le aree dei rettangoli dell'istogramma sono proporzionali al numero di numeri casuali generati che rientrano in quella gamma della scala verticale.
Ora, la conversione di quelle migliaia di successi usando le formule del metodo risulta in
una campana perfettamente adeguata.
Usando il metodo delle coordinate polari proposto sopra, abbiamo convertito il PRNG di MT4 in un PRNG con una variabile casuale normalmente distribuita.
A un tentativo di applicare la formula bayesiana. Di nuovo.
Compito. Usando il teorema di Bayes, determinare quale valore di una zecca che non è ancora arrivata è più probabile.
Dato. Serie temporale x,y.
y=ax+b Una linea dall'ultimo tick al futuro.
P(a,b|x,y)=P(x,y|a,b)*P(a)*P(b)/P(x,y); (1) formula di Bayes.
P(a,b|x,y)è la probabilità che i coefficienti a e b corrispondano alle coordinate x e y di un futuro tick.
Dobbiamo trovare a e b tali che questa probabilità (più correttamente dettamisura di probabilità) sia massima.
P(x,y|a,b) - prendiamo l'istogramma reale della distribuzione dei tick per livelli di prezzo come funzione di verosimiglianza. La funzione è definita da un array bidimensionale (matrice): range di prezzo - probabilità, rapporto percentuale di tick che rientrano in questo range rispetto al numero totale di tick.
P(b) - la distribuzione normale degli incrementi è presa come probabilità a priori b. Viene usato il PRNG con il valore normalmente distribuito.
Il coefficiente P(a) a determina la pendenza della linea retta e il segno dell'incremento previsto. Per ora sto pensando di usare il codice di regressione lineare che ho postato prima. Cioè prendere la probabilità del coefficiente a trovato lì come unità. E in (1) sostituire la probabilità P(a) calcolata tenendo conto della differenza di questa a e quella calcolata per la y data.
Forse avete qualche idea su come si comporta il segno degli incrementi di ogni tick?
Non c'è assolutamente bisogno di mettere le zecche nella formula. Chiunque può generare quelle zecche su FORTS, cosa che viene fatta ogni giorno.
Il problema non è nei metodi matematici, piuttosto. Ma nell'adeguatezza della scelta dei dati da applicare.
Perché prendere dei tic artificiali? Si può imparare a prevederli senza matematica superiore. Chiedete a MQ come.
Quindi la funzione di verosimiglianza P(x,y|a,b) in (1) è la distribuzione reale dei tick reali (volumi di tick). È estremamente raro che sia normale. E P(a) e P(b) sono probabilità correttive, per leggi prese come probabilità a priori.
Cosa chiedere a MQ? Il principio di modellazione dei tick nel tester di strategia? Sì, ci deve essere un principio. Forse sapendolo, potremmo creare dei "grails" di tester. Ma non posso svilupparlo in modalità test, dato che non ho né la cronologia dei tick, né la pratica per lavorarci. Tutto sarà in tempo reale.
Interessato alle sue parole:
"Non faccio affatto regressione e valori di prezzo (o le sue trasformazioni) nei miei esperimenti, prevedo il segno, ma si potrebbe dire che anche questo fa parte dell'informazione sul prezzo.
I miei errori sono così:
0 1
0 0,58 0,42
1 0,43 0,57
O più o meno come in origine:
1 - corretto, 0 - errore: 1, 1, 1, 0, 0, 0, 0, 1 , 1, 1, 0, 1
E la distribuzione di probabilità risultante dovrebbe essere il più diverso possibile da 0,5 / 0,5. Se otteniamo l'inseparabilità reciproca di tali risultati, arriveremo alla distribuzione binomiale, e ci sono molte, molte formule per essa e test statistici" Fine della citazione.
Cosa, la distribuzione binomiale regola veramente nel caso della previsione di un segno? Qual è l'indipendenza reciproca dei risultati? Grazie.
Quindi la funzione di verosimiglianza P(x,y|a,b) in (1) è la distribuzione reale dei tick reali (volumi di tick). È molto raramente normale. E P(a) e P(b) sono probabilità correttive, per leggi prese come probabilità a priori.
Cosa chiedere a MQ? Il principio di modellazione dei tick nel tester di strategia? Sì, ci deve essere un principio. Forse sapendolo, potremmo creare dei "grails" di tester. Ma finora non posso svilupparlo in modalità di test, poiché non ho né la cronologia dei tick, né la pratica di lavorare con esso. Tutto sarà in tempo reale.
Interessato alle sue parole:
"Non faccio affatto regressione e valori di prezzo (o le sue trasformazioni) nei miei esperimenti, prevedo il segno, ma si potrebbe dire che anche questo fa parte dell'informazione sul prezzo.
I miei errori sono così:
0 1
0 0,58 0,42
1 0,43 0,57
O più o meno come in origine:
1 - corretto, 0 - errore: 1, 1, 1, 0, 0, 0, 0, 1 , 1, 1, 0, 1
E la distribuzione di probabilità risultante dovrebbe essere il più diverso possibile da 0,5 / 0,5. Se otteniamo l'indipendenza reciproca di tali risultati, arriviamo alla distribuzione binomiale, e per essa ci sono molte, molte formule e test statistici" Fine della citazione.
La distribuzione binomiale regna davvero nel caso della previsione di un segno? Qual è l'indipendenza reciproca dei risultati? Grazie.
Usare i tick per la previsione è pericoloso secondo me, e il modello dovrebbe essere impostato per ogni broker separatamente.
Se prendiamo i tick dal tester della strategia ci sarà una seria differenza da quelli reali, perché i tick nel tester sono generati da un modello dai valori ohlc delle barre dei minuti(https://www.mql5.com/en/articles/75). Ecco perché nessuno testa mai gli scalper, ma li mette subito su un conto reale e li ottimizza lungo la strada.
A proposito di zecche reali - possono variare molto da broker a broker. Per esempio in questo thread https://www.mql5.com/en/forum/64228/page2#comment_1960403 (https://c.mql5.com/3/78/tbd.png ) è allegata una schermata, questa è la distribuzione degli incrementi di tick sullo stesso time frame in due diversi broker. Non ricordo la durata dell'intervallo, qualcosa da un giorno a una settimana. Generalmente coincidono, ma uno di loro ha due volte più ticks senza cambiamento di prezzo. Se si confrontano più di dieci broker penso che ci possano essere enormi differenze, soprattutto per le "candele a sorpresa".
In alternativa, tutte le zecche possono essere rimosse senza cambiamenti di prezzo. Poi c'è una sfumatura che l'evento OnTick() può essere saltato nell'EA e un nuovo prezzo con quello precedente sarà inviato al terminale. Cioè, non 1,23456 -> 1,23490 -> 1,23410, ma semplicemente 1,23456 -> 1,23410. E invece di due cambiamenti, il vostro modello ne avrà uno solo.
Risulterà che l'intervallo di tempo tra due tick vicini non è definito e ci saranno dei vuoti di dati, penso che sia un male.
Vale ancora la pena provare, è necessario utilizzare MT4 e il programma Tickstory Lite (c'è una versione gratuita) per inserire i tick reali nel tester (sono presi dal broker Dukascopy). Solo il terminale MT4 dovrebbe essere usato con una build inferiore a 950, altrimenti la versione gratuita di tickstory farà dei dati di prova con spread zero.
Ho provato qualcosa con i tick, come trovare una media e comprare e vendere se il prezzo attuale si discosta fortemente dalla media. Se c'era del profitto, allora lo spread si stava mangiando tutto e sono passato a timeframe più grandi.