L'apprendimento automatico nel trading: teoria, modelli, pratica e algo-trading - pagina 195
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
Sì, stavo facendo dei lag perché nelle versioni precedenti aumentavano il potere di avvolgimento, ora con l'algoritmo di prefetching migliorato non è necessario, quindi sto cercando di allenarmi senza di loro. Sto cercando di allenarmi senza di loro. Riferirò i miei risultati più tardi.
Se il trucco non funziona, cioè la capacità di generalizzazione senza ritardi non aumenta, allora la 13a e la 14a versione sono molto probabilmente una sorta di direzione non universale, personalizzata per una gamma ristretta di compiti?
In questo caso, dovrai rollare GIT per spostare jPrediction in un modo diverso, più universale.
Anche se c'è una seconda ipotesi: la presenza di ritardi nel campione è una direzione stretta e non universale, per la quale le versioni precedenti sono state affinate?
Se il trucco fallisce, cioè la generalizzabilità senza ritardi non migliora, allora molto probabilmente la versione 13 e 14 sono alcune direzioni non universali, affilate per una gamma ristretta di compiti?
In questo caso, dovremo rollare GIT per spostare jPrediction in un modo diverso, più universale.
Anche se c'è una seconda ipotesi: la presenza di ritardi nel campione è una direzione stretta e non universale, per la quale le versioni precedenti sono state affinate?
Risponderò qui allora.
dat <- data.frame(cluster1=c(24,2,13,23,6), cluster2=c(5,15,13,28,12), cluster3=c(18,12,16,22,20), cluster4=c(21,7,29,10,25), cluster5=c(16,22,24,4,11), target.label=c(1,1,0,1,0))
dat <- rbind(dat, dat[1,], dat[1,])
#результат последней строки поменян на 0 для эксперимента
dat[7,"target.label"]=0
library(sqldf)
#для sqldf точек в названиях колонок быть не должно
colnames(dat)[6] <- "target"
dat1 <- sqldf( "select cluster1, cluster2, cluster3, cluster4, cluster5, avg(target) as target_avg, count(target) as target_count from dat group by cluster1, cluster2, cluster3, cluster4, cluster5" )
dat1
dat1[ dat1$target_count>=10 & dat1$target_avg>0.63 , ]
dat1[ dat1$target_count>=10 & ( dat1$target_avg<0.37 | dat1$target_avg>0.63 ), ] #на случай если оба "0" или "1" встречаются чаще 70%
Grazie, soluzione molto compatta!!!
Per favore, aiutatemi con un'altra sfumatura nella stringa
dat1 <- sqldf( "select cluster1, cluster2, cluster3, cluster4, cluster5, avg(target) as target_avg, count(target) as target_count from dat group by cluster1, cluster2, cluster3, cluster4, cluster5" )
Come faccio a sostituire i nomi dei cluster selettivi con una sola variabile dire
perché ci saranno 500 o forse anche 1000 cluster nella vita reale, non sarebbe realistico scrivere ogni nome di cluster manualmente, e la soluzione non funziona a testa alta
Bene, vediamo cosa c'è... Ti racconterò non appena l'avrò praticato...
Il punto è che prima della versione 13, i predittori che erano più vicini all'inizio del campione venivano elaborati con maggiore probabilità. E quelli alla fine del campione (più vicini alla variabile obiettivo) sono stati trattati con minore probabilità. Cioè, se i predittori più significativi sono posti a sinistra nel campione in anticipo e quelli meno significativi a destra, otteniamo una buona capacità di generalizzazione. Se viceversa, povero. Il problema era che questo richiedeva di sapere in anticipo quali predittori erano più significativi, cioè preordinarli nel campione in base alla significatività. Ma in quel caso, l'algoritmo di selezione dei predittori non era molto efficiente.
Nella versione 14, la probabilità di elaborazione per tutti i predittori è circa la stessa. Ma questo crea un altro problema. Dopo tutto, l'algoritmo di adattamento del predittore opera su un metodo di ricerca a gradiente, spostando un passo ogni volta verso l'aumento della generalizzazione. Allo stesso tempo ha un rischio non nullo di rimanere "bloccato" su un estremo locale, come altri metodi a gradiente. Prima della versione 12 questo rischio era mitigato da predittori di pre-ranking nel campione.
In generale, ci sono problemi nella prima e nella seconda versione dell'algoritmo e dobbiamo analizzarli per eliminarli. Per esempio, introdurre nell'algoritmo dei salti casuali per diversi passi in direzioni diverse dallo stato attuale, per "saltare" i "burroni".
> clusternames
[1] "cluster1,cluster2,cluster3,cluster4,cluster5"
> sql_query <- paste0("select ", clusternames, ", avg(target) as target_avg, count(target) as target_count from dat group by ", clusternames)
> sql_query
[1] "select cluster1,cluster2,cluster3,cluster4,cluster5, avg(target) as target_avg, count(target) as target_count from dat group by cluster1,cluster2,cluster3,cluster4,cluster5"
> dat1 <- sqldf( sql_query )
> dat1
per "saltare" sui "burroni".
A volte l'ottimizzazione L-BFGS è integrata nella neuronica, permette di uscire dai burroni. Il pacchetto neurale nnet, per esempio.
C'è molta matematica lì, non so come funziona, ma l'idea è di scendere non lungo il gradiente, ma lungo il gradiente dal gradiente (derivata della derivata).
1) Esempio corretto e primitivo (se le reti o ecc. non si trovano da nessuna parte, comincia a "inventare"))
2) Solo perché cercare il 70%, quando si può trovare e usare il 100 (non per il prezzo ovviamente).
1) sì, sì, hanno quel peccato )) l'ho descritto nei paragrafi sui vantaggi del "mio" approccio
2) Cercherò combinazioni su inversioni, non è solo una direzione o un colore della candela ma un'inversione verso l'alto, verso il basso, non un'inversione
Inizialmente ho molte meno osservazioni di quelle di cui ho bisogno, ma se tutto funziona sarò felice con il 40% dei risultati, non ho nemmeno bisogno del 70% perché il mio obiettivo di rischio sarà 1 a 5
Grazie mille, preparerò lentamente i dati, poi li raggrupperò, poi cercherò i modelli e vi farò sapere i risultati
A volte l'ottimizzazione L-BFGS è integrata in neuronki, permette di uscire dai burroni. Il pacchetto neuronki nnet per esempio.
BFGS e i suoi derivati come L-BFGS sono progettati per risolvere il problema che jPrediction ha già risolto, cioè trovare gli estremi locali. Cioè questi algoritmi permettono di "uscire" dai "burroni" in direzione degli estremi più vicini piuttosto che "saltare" i burroni per cercare estremi alternativi.
Abbiamo bisogno di algoritmi "saltatori". Ed è auspicabile che "saltino" non a caso, ma in qualche direzione potenzialmente promettente. Teoricamente, questo può essere implementato attraverso la genetica, dove tali "salti" sono fatti attraverso le mutazioni. Ma gli algoritmi genetici sono molto lenti e più adatti a quei compiti in cui i potenziali discendenti possono essere testati per i pidocchi con un consumo minimo di tempo. Addestrare una neuronkey per calcolare la sua generalizzabilità richiede tempo, quindi la genetica sarebbe troppo lenta in questo caso.
OK, in mancanza di una migliore, sto testando una variante con "salti" casuali.
Un altro libro R. Lo appunterò qui, dato che non è chiaro dove altro andare. Che sia
S.E. Mastitsky, V.K. Shitikov
ANALISI STATISTICA E VISUALIZZAZIONE DEI DATI CON R
Se cercate i modelli come mytarmailS, scorrendo per barra, ogni modello conterrà informazioni su quanto può essere l'intervallo dei valori su ogni barra. Più schemi ci sono, meno intervallo sarà impostato per ogni barra.
In parole povere, affinché una certa finestra con nuovi dati possa essere inclusa in qualche modello trovato in precedenza, essa dovrebbe rientrare in tali limiti veritativi inerenti ad ogni modello.
Se vai a cercare 1000 modelli, la larghezza del "canale" di ogni modello sarà piccola. E poiché i nuovi dati sono sempre leggermente diversi dai dati di allenamento - sarà difficile entrare in un canale così stretto, porterà a degli errori.
Mi farei guidare dall'Occam's Briton - se si può ridurre il numero di modelli e ottenere lo stesso risultato senza deteriorarsi, è meglio farlo.