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

Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Heute wurde ein solcher Prädiktor für den Abstand zum aktuellen Balken hinzugefügt. Sie können eine Nummer oder nur eine Uhrzeit angeben. Ich habe mir die Zeit genommen.
Mit der zyklischen Zeit ist alles mehr oder weniger klar. Ich verstehe nicht viel von der linearen Zeit - wird sie für das Tablett und die Vorwärtsbewegung unterschiedlich sein? Oder wird der "aktuelle Balken" unabhängig für jede Probe genommen?
Ich hatte die Idee, einfach eine gewöhnliche lineare logistische Regression zu nehmen und die Signifikanz des Unterschieds zum Nullkoeffizienten zum Zeitpunkt (oder zu einer Funktion der Zeit) zu sehen oder diese Signifikanz mit der Signifikanz für andere Prädiktoren zu vergleichen.
Die zyklische Zeit ist mehr oder weniger klar. Bei der linearen Zeit ist es nicht ganz klar - wird sie bei einem Tablett und einem Stapel unterschiedlich sein? Oder wird der "aktuelle Balken" unabhängig für jede Probe genommen?
Ich hatte die Idee, einfach eine gewöhnliche lineare logistische Regression zu nehmen und die Signifikanz eines von Null abweichenden Koeffizienten zum Zeitpunkt (oder zu einer Funktion der Zeit) zu sehen oder diese Signifikanz mit der Signifikanz für andere Prädiktoren zu vergleichen.
Eine Sinuswelle steht für zyklische Zeiten wie Tageszeit oder Wochentag. Ursprünglich sprach Aleksey Vyazmikin von der gewöhnlichen linearen Zeit, um zu versuchen, den Effekt der Nicht-Stationarität in Form des Musterzerfalls zu erfassen. Meiner Meinung nach sollten zur Lösung solcher Probleme einfache, leicht interpretierbare Modelle verwendet werden. Komplexe Modelle dienen praktischen Zwecken, einfache Modelle der vorläufigen Analyse.
Es bestehen jedoch Zweifel an der praktischen Nützlichkeit solcher Tricksereien in diesem speziellen Fall. Wahrscheinlich ändern sich unsere Muster nicht gleichmäßig im Laufe der Zeit, sondern zyklisch (aber ohne Periodizität).
Eine Sinuswelle steht für zyklische Zeiten wie Tageszeit oder Wochentag. Ursprünglich sprach Aleksey Vyazmikin von der gewöhnlichen linearen Zeit, um den Effekt der Nicht-Stationarität in Form des Musterzerfalls zu erfassen. Meiner Meinung nach sollten zur Lösung solcher Probleme einfache, leicht interpretierbare Modelle verwendet werden. Komplexe Modelle dienen praktischen Zwecken, einfache Modelle der vorläufigen Analyse.
Es bestehen jedoch Zweifel an der praktischen Nützlichkeit solcher Tricksereien in diesem speziellen Fall. Höchstwahrscheinlich ändern sich unsere Regelmäßigkeiten im Laufe der Zeit nicht gleichmäßig, sondern zyklisch (aber ohne Periodizität).
Generell ist die Idee, lineare Zeit zu füttern, schlecht. Übrigens, ja: auf dem Tablett ist es in jeder Zeile anders und auf dem Vorwärtsgang analysieren wir jeweils nur 1 Zeile, d.h. die Zeit wird immer aktuell sein (was im Tablett nicht der Fall war) und die Zahl immer = 0 (und im Tablett von 0 bis 5000). D.h. es kann weder eine Uhrzeit noch eine Fachnummer angegeben werden. Das hat der Test ergeben.
Obwohl ich es noch einmal mit der Nummer versuchen werde... Denn die Nullnummer wird in den Teil des Baumes aufgenommen, der < einem bestimmten Split (z.B. <5000) ist, d.h. ein Teil des Baumes wird für die Weiterleitung verwendet. Nicht alles davon. Etwas, für das ich mir aus Versehen Zeit genommen habe, um es zu testen.
Aber wie macht man einen Split nach Nummer war in einem optimalen Abstand für vorwärts?
Ich habe es ausprobiert. Das Modell mit 5000 Balken der Geschichte zu lernen, nach Hinzufügen der Zeilennummer als ein Merkmal, für Buy verbessert, für Sell in gewisser Weise schlechter, in gewisser Weise besser.
Wenn wir jedoch mit 10000 Takten unterrichten, werden beide Modelle defizitär. D.h. die Hauptaufgabe der Hinzufügung der Zeilennummer zur automatischen Ermittlung der notwendigen Historienlänge ist nicht erfüllt.
Bislang müssen wir nur die Länge der Lernhistorie manuell optimieren/auswählen.
Der Grundgedanke bei der Verwendung benutzerdefinierter Händlermetriken scheint zu sein, dass sie in der Phase der Modellauswahl verwendet werden. In der Trainingsphase werden die Standardmetriken verwendet. Wahrscheinlich ist es so ähnlich wie das, was Maxim Dmitrievsky früher zu diesem Thema geschrieben hat.
Ein kleiner Artikel zur Veranschaulichung des Ansatzes.
Der Hauptgedanke bei der Verwendung von Metriken für benutzerdefinierte Händler ist, dass sie in der Phase der Modellauswahl verwendet werden.
Es gibt jedoch einige Ideen zur Verwendung benutzerdefinierter Metriken in der Ausbildungsphase. Gleichzeitig sind sie nicht ganz so ähnlich wie die von Händlern, sondern eher modifizierte Versionen von Standardmodellen für MO.
Vielleicht führen Händlermetriken zu einer schlechten Konditionalität. Dies erinnert zum Beispiel an die Verwendung der Kreuzentropie anstelle der ursprünglichen Fehlerquote (letztere gilt als wenig empfindlich).
Es ist notwendig, die theoretischen und praktischen Lücken zwischen der Ausbildung im IR und der Optimierung im Prüfer irgendwie zu verringern.
Allerdings gibt es bereits in der Ausbildungsphase einige Ideen zur Verwendung benutzerdefinierter Metriken. Sie sind jedoch nicht genau wie die Metriken von Händlern, sondern eher abgewandelte Varianten der Standard-MOE-Metriken.
Vielleicht führen Händlermetriken zu einer schlechten Konditionalität. Es ähnelt zum Beispiel der Verwendung der Kreuzentropie anstelle der ursprünglichen Fehlerhäufigkeit, die von Interesse ist(sie sagen, dass letztere wenig empfindlich ist).
Wir müssen irgendwie die theoretischen und praktischen Lücken zwischen der Ausbildung in MO und der Optimierung im Tester reduzieren.
Als ich noch mit TP/SL Modelle baute, war die Genauigkeit absolut. Im Modell und im Tester wurden die Geschäfte an denselben Stäben eröffnet und mit denselben TP/SL geschlossen. Aber die Rentabilität lag bei 0.
Ich testete auf der Grundlage der offenen Preise. Aber es gibt ein Problem mit ihnen... Die Mindestspanne wird in der Leiste verwendet.
Das heißt, ein Teil der Aufträge und TP/SL im Tester wird bei
ASK HIGH = BID HIGH + Mindestspanne.
Diejenigen, die im realen Handel ausgelöst werden würden, funktionieren nicht.
ASK HIGH (real) = BID HIGH + Spanne, berechnet aus dem maximalen ASK
Ich habe den Entwicklern schon mehrmals vorgeschlagen, nicht die Mindestspanne in Balken zu speichern, sondern
Spanne = ASK HIGH - BID HIGH.
Bei einer solchen Spanne käme das Testen anhand der offenen Preise dem Testen anhand echter Ticks näher.
Zum Beispiel: Mindestspread für einen Barren = 0,00002, während Spread = ASK HIGH - BID HIGH = 0,00020. D.h. in Wirklichkeit war der ASK-Preis um 0,00018 höher als der des Testers. Wo die Handelseröffnungen/-abschlüsse stattgefunden haben könnten.
Aber es gab keine Antwort von MetaQuotes (auf Russisch)
PS: Um genauer zu sein, sollte auch der Low Ask Spread berechnet werden.