Bibliotheken: BestInterval - Seite 13
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
Ich habe auf die letzte Version von BestInterval und Virtual aktualisiert.
Beim Kompilieren mit neuen Zeilen am Anfang des Codes bekam viele Fehler. Am Ende nur 3 (siehe Bild).
Vielen Dank für Ihre Hilfe
Setzen Sie diese Zeilen an den Anfang, nicht an das Ende.
Normalerweise landet ein solcher Backtest direkt während der Optimierung im Papierkorb (oder in einem einzigen Durchgang)
Mit BestInterval während der Optimierung wird dieser Durchgang jedoch einer der besten sein. Grund
Der Nachteil ist, dass es keine Metriken gibt, um festzustellen, inwieweit es nicht zu dem zu optimierenden Intervall passt
Zum Beispiel zeichnet meine Bibliothek genau dasselbe für 1 Durchgang im Tester, aber sie wirft keine Intervalle raus, sondern dreht verlorene Trades um und approximiert eine neue Sequenz.
Es stellt sich heraus, dass Bestinterval umso schönere Bilder zeigt, je mehr Trades im anfänglichen TS enthalten sind, und es spielt keine Rolle, wie die Verteilung der Trades davor war.
Der Nachteil ist, dass es keine Metriken gibt, um festzustellen, inwieweit es nicht zu dem zu optimierenden Intervall passt
Sie können jede beliebige Metrik für OnTester schreiben. Die Bibliothek erlaubt das.
Meine Bibliothek zeichnet zum Beispiel genau das Gleiche für 1 Durchgang im Tester, nur dass sie keine Intervalle verwirft, sondern verlorene Trades umkehrt und eine neue Sequenz approximiert.
Es stellt sich heraus, dass Bestinterval umso schönere Bilder zeigt, je mehr Trades im anfänglichen TS sind, und es spielt keine Rolle, wie die Verteilung der Trades davor war.
Zweideutige Aussage. Ich bestimme die Anpassung einfach - ich nehme EIN bestes Ergebnis von BestInterval und lasse es (einzeln) auf einem doppelt so großen Intervall laufen. Wenn die Erweiterung des Intervalls den Charakter der direkten Bilanz nicht verändert - ist es keine Anpassung. In der zweiten Abbildung oben > 1000 Trades. Wenn ich das Intervall verdopple, bleibt die gerade Linie erhalten. D.h. es handelt sich nicht um eine 100%ige Anpassung.
Eine andere Sache ist, dass "nicht passend" nur eine Sache bedeutet - die Muster wurden als echt erkannt. Aber nichts garantiert, dass sie sich fortsetzen werden. Und diese fehlende Garantie ist kein Hinweis auf irgendeine Art von Übereinstimmung. Das ist einfach ein Gesetz des Lebens.
Sie können jede beliebige Metrik für OnTester schreiben. Die Bibliothek erlaubt.
Zweideutige Aussage. Ich definiere Anpassung einfach - ich nehme EIN bestes Ergebnis von BestInterval und führe es (einzeln) auf einem doppelt so großen Intervall aus. Wenn die Erweiterung des Intervalls den Charakter der direkten Bilanz nicht verändert, handelt es sich nicht um ein Fitting. In der zweiten Abbildung oben > 1000 Trades. Wenn ich das Intervall verdopple, bleibt die gerade Linie bestehen. D.h. keine 100%ige Anpassung.
Eine andere Sache ist, dass "nicht passend" nur eine Sache bedeutet - die Muster wurden als real empfunden. Aber nichts garantiert, dass sie sich fortsetzen werden. Und diese fehlende Garantie ist kein Hinweis auf irgendeine Art von Passung. Das ist nur ein Gesetz des Lebens.
Im Allgemeinen betreiben Sie reines maschinelles Lernen, aber aus irgendeinem Grund ignorieren Sie dieses Thema :)
Ja, wenn Sie einige Metriken einbauen und Modelle auf der Grundlage dieser Metriken aussortieren, dann wird die Überanpassung reduziert, das ist mein Punkt. Im Idealfall wählt die Maschine das beste Modell aus, das mit größerer Wahrscheinlichkeit auch etwas über OOS aussagt.
Im Allgemeinen beschäftigen Sie sich mit reinem maschinellem Lernen, aber aus irgendeinem Grund ignorieren Sie dieses Thema :)
Ich kann es nicht verstehen.
Ja, wenn Sie einige Metriken einbauen und Modelle auf der Grundlage dieser Metriken aussieben, dann wird nur die Routine der Suche reduziert, das ist mein Punkt. Im Idealfall wird automatisch das beste Modell ausgewählt, das mit einer höheren Wahrscheinlichkeit auf dem OOS auch etwas zeigen wird.
Nun, wenn es um Größenordnungen mehr Rechenressourcen gäbe, würde kein BestInterval benötigt werden. D.h. es gibt hier keine Andeutung von MO. Es handelt sich lediglich um einen Filter, der bequem und schnell anzuwenden ist, mehr nicht.
Was die OOS-Wahrscheinlichkeit betrifft, so wird sie genau so bestimmt, wie ich oben gesagt habe. Das heißt, jeder Auswahl-/Optimierungsfaktor wird eliminiert. Entweder ist alles gut oder schlecht.
Eine viel kompliziertere Frage ist, wenn es einen funktionierenden TS gibt und es notwendig ist, die Werte der optimalen Eingangsparameter für den realen zu wählen.
Ich entdeckte, dass GA+BestInterval ein ekelhaftes Mapping ist. Das heißt, es kommt zu einer Konvergenz zu einem lokalen Extremwert, und wenn man das überprüft, stellt sich heraus, dass es eine absolute Passung ist.
Buteforce+BestInterval ist ein hervorragendes Mapping, wie sich herausstellt. Wo GA mich glauben ließ, dass der TC Unsinn sei, zeigte Bruteforce vielversprechend.
Nun, damit Bruteforce schnell ist, braucht man eine kleine Anzahl von Ticks und eine schnelle TC-Logik. Aus diesem Grund liefern alle Beschleunigungsmechanismen nicht nur quantitative, sondern auch qualitative Ergebnisse.
GA selbst ist so gut wie die Milch vom Stier ) Es gilt als eine explorative Optimierung, die in Bezug auf die Verlässlichkeit der Ergebnisse überhaupt nichts schuldet.
Ich kann mich mit GA nicht anfreunden.