Maschinelles Lernen im Handel: Theorie, Modelle, Praxis und Algo-Trading - Seite 195

 
Mihail Marchukajtes:
Ja, ich habe Lags gemacht, weil sie in früheren Versionen die Umhüllungsleistung erhöht haben. Jetzt, mit dem verbesserten Prefetching-Algorithmus, glaube ich nicht, dass das nötig ist, also versuche ich, ohne sie zu trainieren. Ich versuche, ohne sie zu trainieren. Ich werde später über meine Ergebnisse berichten.

Wenn ich versage, d.h. die Verallgemeinerbarkeit nicht ohne Verzögerungen zunimmt, dann sind die 13-te und 14-te Version höchstwahrscheinlich eine nicht-universelle Richtung, die für einen engen Bereich von Aufgaben bestimmt ist?

In diesem Fall müssen Sie GIT zurücksetzen, um jPrediction auf eine andere, universellere Weise zu verschieben.

Es gibt zwar eine zweite Hypothese: Das Vorhandensein von Lags in der Stichprobe ist eine enge und nicht universelle Richtung, für die die früheren Versionen geschliffen wurden?

 
Yury Reshetov:

Wenn der Trick fehlschlägt, d.h. die Verallgemeinerbarkeit ohne Verzögerungen sich nicht verbessert, dann sind Version 13 und 14 höchstwahrscheinlich eine nicht-universelle Richtung, die für einen engen Bereich von Aufgaben geschärft wurde?

In diesem Fall müssen wir GIT zurückdrehen, um jPrediction auf eine andere, universellere Weise zu verschieben.

Es gibt zwar eine zweite Hypothese: Das Vorhandensein von Lags in der Stichprobe ist eine enge und nicht universelle Richtung, für die die früheren Versionen geschliffen wurden?

Nun, mal sehen, was los ist... Ich werde sofort berichten, sobald ich geübt habe...
 
Dr. Trader:

Ich werde dann hier antworten.

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

Danke, sehr kompakte Lösung!!!

Bitte helfen Sie bei einer weiteren Nuance in der Zeichenfolge


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

Wie kann ich die selektiven Clusternamen durch eine Variable ersetzen?

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

da es in der Realität 500 oder vielleicht sogar 1000 Cluster geben wird, wäre es unrealistisch, jeden Clusternamen manuell zu schreiben, und die Lösung funktioniert nicht direkt.

 
Mihail Marchukajtes:
Nun, mal sehen, was da los ist... Ich werde dir davon erzählen, sobald ich es geübt habe...

Der Punkt ist, dass vor Version 13 die Prädiktoren, die näher am Anfang der Stichprobe lagen, mit höherer Wahrscheinlichkeit verarbeitet wurden. Diejenigen am Ende der Stichprobe (näher an der Zielvariablen) wurden mit geringerer Wahrscheinlichkeit bearbeitet. Das heißt, wenn die signifikantesten Prädiktoren in der Stichprobe im Voraus links und die weniger signifikanten rechts platziert werden, erhalten wir eine gute Generalisierungsfähigkeit. Wenn es umgekehrt ist, dann schlecht. Das Problem bestand darin, dass dazu im Voraus bekannt sein musste, welche Prädiktoren am signifikantesten waren, d. h. sie mussten in der Stichprobe nach ihrer Signifikanz geordnet werden. Aber in diesem Fall war der Algorithmus zur Auswahl der Prädiktoren selbst nicht sehr effizient.

In Version 14 ist die Verarbeitungswahrscheinlichkeit für alle Prädiktoren ungefähr gleich. Dies führt jedoch zu einem weiteren Problem. Der Algorithmus zur Prädiktorenanpassung arbeitet mit einer Gradientensuche, bei der jedes Mal ein Schritt zur Verbesserung der Verallgemeinerung getan wird. Gleichzeitig besteht ein von Null abweichendes Risiko, an einem lokalen Extremwert "hängen zu bleiben", wie bei anderen Gradientenmethoden. Vor Version 12 wurde dieses Risiko durch eine Vorabeinstufung der Prädiktoren in der Stichprobe gemildert.

Im Allgemeinen gibt es Probleme in der ersten und zweiten Version des Algorithmus und wir müssen sie analysieren, um sie zu beseitigen. Zum Beispiel, um in den Algorithmus einige zufällige Sprünge für mehrere Schritte in verschiedene Richtungen vom aktuellen Zustand aus einzuführen, um über die "Schluchten" zu "springen".

 
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:

über "Schluchten" zu "springen".

Manchmal ist die L-BFGS-Optimierung in die Neuronen eingebaut, sie ermöglicht es, aus Schluchten herauszuklettern. Das neuronale Paket nnet, zum Beispiel.

Ich weiß nicht, wie das funktioniert, aber die Idee ist, nicht entlang der Steigung abzusteigen, sondern entlang der Steigung von der Steigung (Ableitung der Ableitung).

 
Eidechse_:
1) Richtig verstandenes und primitives Beispiel (wenn keine Netze oder ähnliches zu finden sind, fängt es an zu "erfinden")))
2) Warum nur 70 % suchen, wenn man auch 100 finden und nutzen kann (natürlich nicht zum gleichen Preis).

1) ja, ja, sie haben diese Sünde )) ich habe sie in Absätzen über die Vorteile "meines" Ansatzes beschrieben

2) Ich werde nach Kombinationen auf Umkehrungen suchen, es ist nicht nur eine Richtung oder Farbe der Kerze, sondern eine Umkehrung nach oben, nach unten, nicht Umkehrung

Anfangs habe ich viel weniger Beobachtungen als nötig, aber wenn alles funktioniert, bin ich mit 40 % der Ergebnisse zufrieden. Ich brauche nicht einmal 70 %, da mein Zielrisiko bei 1 zu 5 liegen wird.

Dr. Trader:

Vielen Dank, ich werde die Daten langsam aufbereiten, dann clustern, dann nach Mustern suchen, und ich werde Sie über die Ergebnisse informieren.

 
Dr. Trader:

Manchmal ist die L-BFGS-Optimierung in Neuronki eingebaut, die es ermöglicht, aus den Schluchten herauszukommen. Das nnet neuronkey-Paket zum Beispiel.

BFGS und seine Ableitungen wie L-BFGS sind darauf ausgelegt, das Problem zu lösen, das jPrediction bereits gelöst hat, nämlich lokale Extrema zu finden. D.h. diese Algorithmen ermöglichen das "Herausklettern" aus "Schluchten" in Richtung der nächstgelegenen Extrema, anstatt über Schluchten zu "springen", um nach alternativen Extremen zu suchen.

Wir brauchen Algorithmen "Jumper". Und es ist wünschenswert, dass sie nicht wahllos "springen", sondern in eine vielversprechende Richtung. Theoretisch kann dies durch die Genetik realisiert werden, wo solche "Sprünge" durch Mutationen erfolgen. Genetische Algorithmen sind jedoch sehr langsam und eignen sich eher für solche Aufgaben, bei denen potenzielle Nachkommen mit minimalem Zeitaufwand auf Läuse getestet werden können. Das Training eines Neuronenschlüssels zur Berechnung seiner Verallgemeinerungsfähigkeit ist zeitaufwendig, so dass die Genetik hier zu langsam wäre.

OK, in Ermangelung eines besseren Begriffs, teste ich gerade eine Variante mit zufälligen "Sprüngen".

 

Ein weiteres R-Buch. Ich werde es hier anheften, da ich nicht weiß, wo es sonst hingehört. Lass es sein.

S.E. Mastitsky, V.K. Shitikov

STATISTISCHE ANALYSE UND DATENVISUALISIERUNG MIT R

Dateien:
 

Wenn Sie als mytarmailS nach Mustern suchen, die nach Balken gleiten, enthält jedes Muster Informationen darüber, wie groß das Intervall zwischen den Werten in jedem Balken sein kann. Je mehr Muster, desto weniger Intervalle werden für jeden Takt festgelegt.

Grob gesagt: Damit ein bestimmtes Fenster mit neuen Daten in ein früher gefundenes Muster aufgenommen werden kann, muss es in die jedem Muster innewohnenden veritablen Grenzen fallen.

Wenn Sie 1000 Muster suchen, wird die "Kanalbreite" jedes Musters klein sein. Und da sich neue Daten immer leicht von den Trainingsdaten unterscheiden, wird es schwierig sein, in einen solch engen Kanal zu gelangen, was zu Fehlern führen wird.

Ich würde mich von Occam's Briton leiten lassen - wenn man die Anzahl der Muster reduzieren und das gleiche Ergebnis ohne Verschlechterung erzielen kann, sollte man es tun.