Bibliotheken: BestInterval - Seite 23

Neuer Kommentar
 
fxsaber:

Das ist das einzige, was ich bisher getan habe

Der Rest ist nicht erforderlich, um durch Lose korrigiert werden. Aber es gibt Fehler im Zusammenhang mit dem anderen (alten). Es ist notwendig, zu korrigieren.

Aktualisiert. Bei aktiviertem BestInterval-Modus empfehle ich, diese Option zu verwenden.

Forum zum Thema Handel, automatisierte Handelssysteme und Testen von Handelsstrategien

Bibliotheken: Virtuell

fxsaber, 2019.12.11 12:15 Uhr.

Es ist schwer zu sagen, wann die Entwickler die Situation mit der Normalisierung der anfänglichen Symbolpreise beheben werden und ob sie es überhaupt tun werden. Aus diesem Grund wurde dieser Modus eingeführt. 
// https://www.mql5.com/ru/forum/321656/page34#comment_14192799
#define  TICKS_FORCE_NORMALIZE // Erzwungene Normalisierung der eingehenden Tick-Preise
 

Völlig unerwartetes Verhalten.

Es scheint, dass, wenn Sie es einmal mit Action=false ausführen, es das Ergebnis des Durchlaufs in einer Datei speichert und es später anwenden kann. Aber das Unerwartete ist, dass auch alle Parameter wie Total, RF, DD usw. gespeichert werden. Mit anderen Worten, wenn Sie das Programm mit Action=true in einem anderen Intervall desselben Symbols, eines anderen Symbols usw. ausführen, wird es nicht nur den besten Zeitpunkt für den Handel anwenden, sondern auch im Protokoll die alten Werte angeben.

 
traveller00:

Wenn Sie es dann mit Action=true auf einem anderen Intervall desselben Symbols, eines anderen Symbols usw. ausführen, wird es nicht nur den besten Zeitpunkt für den Handel anwenden, sondern auch im Protokoll liegen und die alten Werte angeben.

Es werden nicht die Werte des wahren Laufs angezeigt, sondern die Daten des falschen Laufs, der angewendet wurde. Sie können das Symbol, das Intervall usw. ändern, die angezeigten Werte werden sich nicht ändern. Sie beziehen sich nur auf den Zeitpunkt, an dem der Eintrag vorgenommen wurde. Dies geschieht absichtlich.

 
Vorsorglich möchte ich darauf hinweisen, dass es aus Sicht der Architektur nicht korrekt mit StopLoss funktioniert. Theoretisch kann der bei action=false ausgelöste StopLoss in den Bereich fallen, den BestInterval auswirft. Folglich wird er bei action=true verschoben, und die Ergebniszahlen können manchmal sehr unterschiedlich zu denen sein, die bei action=false vorhergesagt werden.
 
traveller00:
Vorsorglich möchte ich darauf hinweisen, dass es aus Sicht der Architektur nicht korrekt mit StopLoss funktioniert. Theoretisch kann ein StopLoss, der bei action=false ausgelöst wird, in den Bereich fallen, den BestInterval zu verwerfen beschließt. Infolgedessen verschiebt er sich bei action=true, und die Ergebniszahlen können sich manchmal stark von denen unterscheiden, die bei action=false vorhergesagt wurden.

Es scheint, dass Sie etwas missverstehen. Auch theoretisch sollte es keine Probleme geben.

 
Ja, das Problem scheint zu sein, dass Sync, das in Virtual enthalten ist und BestInterval verwendet, StopLoss und TakeProfit ignoriert. Das Problem ist nicht die Architektur, sondern dass ich es nicht ganz verstehe.
 
traveller00:
Ja, das Problem scheint zu sein, dass Sync, das in Virtual enthalten ist und BestInterval verwendet, StopLoss und TakeProfit ignoriert. Das Problem ist nicht architektonisch, sondern dass ich es nicht ganz verstehe.

Ich schreibe TC über Limiter und Taker, also wäre es gut, ein primitives Beispiel für die Reproduktion des Problems zu zeigen.

 
Bei active=true in BestInterval.mqh gibt es voidOnTick( void ), darin SYNC::Positions<BEST_TIME>();, was in Sync.mqh zu staticvoid Positionen( constint Handle = 0, constbool Reverse = false ). Darin werden die Lots neu berechnet, und wenn sie in das erforderliche Intervall fallen, werden sie über SYNC::NewOrderSend(_Symbol, Type, ::MathAbs(AddLots), Price, 100, 0, 0, 0);; aus der virtuellen Umgebung in die reale übertragen. Es ist etwas seltsam, dass der Preis nicht aus den Positionen übernommen, sondern an Ort und Stelle gelesen wird, aber das ist in Ordnung. Wie Sie sehen können, werden StopLoss und TakeProfit mit Null übergeben. Vielleicht verwenden Sie die Option BESTINTERVAL_LIMITSYNC_NETTING, bei der TakeProfit berücksichtigt wird.
 
traveller00:
Bei active=true in BestInterval.mqh gibt es voidOnTick( void ), darin SYNC::Positions<BEST_TIME>();, was in Sync.mqh zu staticvoid Positionen( constint Handle = 0, constbool Reverse = false ). Darin werden die Lots neu berechnet, und wenn sie in das erforderliche Intervall fallen, werden sie über SYNC::NewOrderSend(_Symbol, Type, ::MathAbs(AddLots), Price, 100, 0, 0, 0);; aus der virtuellen Umgebung in die reale übertragen. Es ist etwas seltsam, dass der Preis nicht aus den Positionen übernommen, sondern an Ort und Stelle gelesen wird, aber das ist in Ordnung. Wie Sie sehen können, werden StopLoss und TakeProfit mit Null übergeben. Vielleicht verwenden Sie die Option BESTINTERVAL_LIMITSYNC_NETTING, bei der TakeProfit berücksichtigt wird.

Ja, ich verwende diesen Modus. Der True-Modus diente eher zur Demonstration. Ich habe nicht einmal daran gedacht, Zeit auf eine universelle Lösung zu verschwenden, denn dann wäre alles umsonst gewesen.

Wenn Sie ein wenig basteln, können Sie BestInterval-true für einzelne Durchläufe von EAs mit geschlossenem Quellcode (Market, etc.) verwenden.

Aber das Hauptmerkmal von BestInterval ist immer noch die Arbeit im Optimierungsmodus. True ist eine gute, aber nicht zwingend erforderliche Funktion.

  
  int FromFile( const string FileName = __FILE__, const int CommonFlag = 0 )
  {
    const bool Res = (::FileLoad(FileName, this.Intervals, CommonFlag) > 0) && (this.IsCalculated = true);

    if (Res)
    {
      this.AmountDeleteIntervals = ::ArraySize(this.Intervals) - (this.Intervals[0].OpenTime ? 0 : 1);

      this.FullInterval.Calculate(this.Intervals);
    }
    else
      ::Print("ERROR: Can not load the File " + FileName + "!");

    return(Res);
  }
Kleine kosmetische Korrektur, int => bool. Oder, wenn ich vorschlagen darf, stattdessen AmountDeleteIntervals zurückgeben.
1...1617181920212223242526272829
Neuer Kommentar