L'apprentissage automatique dans la négociation : théorie, modèles, pratique et algo-trading - page 195

 
Mihail Marchukajtes:
Oui, je faisais des lags car dans les versions précédentes ils augmentaient la puissance d'enveloppement, maintenant avec l'algorithme de prefetching amélioré ce n'est plus nécessaire, donc j'essaie de m'entraîner sans eux. J'essaie de m'entraîner sans eux. Je vous ferai part de mes résultats plus tard.

Si l'astuce ne fonctionne pas, c'est-à-dire que la capacité de généralisation sans décalage n'augmente pas, alors les 13e et 14e versions sont très probablement une sorte de direction non universelle, adaptée à une gamme étroite de tâches ?

Dans ce cas, vous devrez rétablir GIT pour déplacer jPrediction d'une manière différente, plus universelle.

Bien qu'il existe une deuxième hypothèse : la présence de retards dans l'échantillon est une direction étroite et non universelle, pour laquelle les versions précédentes ont été affinées ?

 
Yury Reshetov:

Si l'astuce échoue, c'est-à-dire que la généralisation sans décalage ne s'améliore pas, alors il est fort probable que les versions 13 et 14 constituent une direction non universelle, affinée pour une gamme étroite de tâches ?

Dans ce cas, nous devrons rétablir GIT pour déplacer jPrediction d'une manière différente, plus universelle.

Bien qu'il existe une deuxième hypothèse : la présence de retards dans l'échantillon est une direction étroite et non universelle, pour laquelle les versions précédentes ont été affinées ?

Eh bien, voyons ce qu'il en est... Je ferai un rapport dès que je m'entraînerai...
 
Dr. Trader:

Je répondrai ici alors.

#пара строк из той таблицы, не буду я всё текстом копировать, потом первая строка повторена ещё дважды
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%

Merci, une solution très compacte !!!

S'il vous plaît, aidez-nous avec une nuance de plus dans la chaîne.


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" )

Comment remplacer les noms des clusters sélectifs par une seule variable ?

colnames_dat <- colnamed(dat) [-"target"]
dat1 <- sqldf( "select colnames_dat, avg(target) as target_avg, count(target) as target_count from dat group by colnames_dat" )

parce qu'il y aura 500 ou peut-être même 1000 clusters en réalité, il serait irréaliste d'écrire chaque nom de cluster manuellement, et la solution ne fonctionne pas de front

 
Mihail Marchukajtes:
Eh bien, voyons ce qu'il y a... Je vous en parlerai dès que je l'aurai pratiqué...

Le fait est qu'avant la version 13, les prédicteurs qui étaient plus proches du début de l'échantillon étaient traités avec une plus grande probabilité. Et ceux qui se trouvent à la fin de l'échantillon (plus proches de la variable cible) ont été traités avec une probabilité plus faible. Autrement dit, si les prédicteurs les plus significatifs sont placés à l'avance à gauche dans l'échantillon et les moins significatifs à droite, nous obtenons une bonne capacité de généralisation. Si c'est l'inverse, alors pauvre. Le problème est que cela nécessite de savoir à l'avance quels sont les prédicteurs les plus significatifs, c'est-à-dire de les préclasser dans l'échantillon en fonction de leur importance. Mais dans ce cas, l'algorithme de sélection du prédicteur lui-même n'était pas très efficace.

Dans la version 14, la probabilité de traitement pour tous les prédicteurs est à peu près la même. Mais cela crée un autre problème. Après tout, l'algorithme d'ajustement du prédicteur fonctionne selon une méthode de recherche par gradient, en déplaçant chaque fois un pas vers l'augmentation de la généralisation. En même temps, elle présente un risque non nul de rester "coincée" à un extremum local, comme les autres méthodes de gradient. Avant la version 12, ce risque était atténué par le pré-classement des prédicteurs dans l'échantillon.

En général, il y a des problèmes dans la première et la deuxième version de l'algorithme et nous devons les analyser afin de les éliminer. Par exemple, introduire dans l'algorithme des sauts aléatoires de plusieurs pas dans des directions différentes de l'état actuel, afin de "sauter" par-dessus les "ravins".

 
mytarmailS:

> clusternames <- paste(colnames(dat)[-ncol(dat)], collapse=",")
>
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

 
Yury Reshetov:

pour "sauter" par-dessus des "ravins".

Parfois, l'optimisation L-BFGS est intégrée à la neuronique, elle permet de sortir des ravins. Le paquet neuronal nnet, par exemple.

Il y a beaucoup de mathématiques là-dedans, je ne sais pas comment ça marche, mais l'idée est de descendre non pas le long du gradient, mais le long du gradient à partir du gradient (dérivée de la dérivée).

 
Vizard_:
1) Exemple correctement compris et primitif (si les filets ou etc. sont introuvables, il commence à "inventer"))))
2) Seulement pourquoi chercher 70%, quand on peut trouver et utiliser 100 (pas pour le prix bien sûr).

1) oui, oui, ils ont ce péché ;) je l'ai décrit dans des paragraphes sur les avantages de "mon" approche.

2) Je chercherai des combinaisons sur les renversements, il ne s'agit pas seulement d'une direction ou d'une couleur de bougie mais d'un renversement à la hausse, à la baisse, et non d'un renversement.

Au départ, j'ai beaucoup moins d'observations que ce dont j'ai besoin, mais si tout fonctionne, je me contenterai de 40 % des résultats. Je n'ai même pas besoin de 70 %, car mon risque cible sera de 1 à 5.

Dr. Trader:

Merci beaucoup, je vais préparer lentement les données, puis les regrouper, puis chercher des modèles et je vous ferai part des résultats.

 
Dr. Trader:

Parfois, l'optimisation L-BFGS est intégrée à neuronki, elle permet de sortir des ravins. Le paquet neuronki nnet par exemple.

BFGS et ses dérivés tels que L-BFGS sont conçus pour résoudre le problème que jPrediction a déjà résolu, à savoir trouver les extrema locaux. En d'autres termes, ces algorithmes permettent de "sortir" des "ravins" en direction de l'extrema le plus proche plutôt que de "sauter" par-dessus les ravins afin de rechercher d'autres extrema.

Nous avons besoin de "sauteurs" d'algorithmes. Et il est souhaitable qu'ils ne "sautent" pas au hasard, mais dans une direction potentiellement prometteuse. En théorie, cela peut être mis en œuvre par la génétique, où de tels "sauts" sont effectués par des mutations. Mais les algorithmes génétiques sont très lents et conviennent mieux aux tâches où les descendants potentiels peuvent être testés pour les poux avec une consommation de temps minimale. L'entraînement d'une clé neuronale pour calculer sa capacité de généralisation prend du temps, la génétique serait donc trop lente ici.

OK, faute de mieux, je suis en train de tester une variante avec des "sauts" aléatoires.

 

Un autre livre R. Je vais l'épingler ici, car je ne sais pas où le mettre. Laisse faire.

S.E. Mastitsky, V.K. Shitikov

ANALYSE STATISTIQUE ET VISUALISATION DES DONNÉES AVEC R

Dossiers :
 

Si vous recherchez des motifs comme mytarmailS, en glissant par barre, chaque motif contiendra des informations sur l'intervalle que peuvent représenter les valeurs de chaque barre. Plus il y a de motifs, moins il y aura d'intervalle pour chaque mesure.

En gros, pour qu'une certaine fenêtre contenant de nouvelles données soit incluse dans un modèle trouvé précédemment, elle doit se situer dans les limites verticales inhérentes à chaque modèle.

Si vous allez chercher 1000 motifs, la largeur du "canal" de chaque motif sera petite. Et comme les nouvelles données sont toujours légèrement différentes des données de formation, il sera difficile d'entrer dans un canal aussi étroit, ce qui entraînera des erreurs.

Je serais guidé par le briton d'Occam - si vous pouvez réduire le nombre de motifs et obtenir le même résultat sans détérioration, vous feriez mieux de le faire.