Bibliotheken: MT4Orders QuickReport - Seite 6

Neuer Kommentar
 
Forester #:

Die Informationen über den maximalen Long Drawdown sind interessant. Ich habe sie für die gesamte Reihe von Strings erstellt. Ich habe den Code auf der Website noch nicht aktualisiert.
Aber es ist nicht ganz klar, wofür das Datum ist. Wenn wir eine Unterteilung in Rückwärts- und Vorwärtstests vornehmen (wie ich vorgeschlagen habe), dann müssen wir die Statistiken über sie separat in 2 Tabellen berechnen (die maximalen Drawdown-Perioden werden auch dort zu finden sein).

Ich habe eine vollständige Berechnung der Statistiken für Back-/Forward-Tests vorgenommen
.

Die Datei ist aktualisiert worden.
 
Forester #:

Was bei dem Datum nicht ganz klar ist, ist, wofür es steht.

Wenn Sie es ab 2020 sehen wollen - bitte. Von 2023, kein Problem. Es ist nur so, dass es Ihnen manchmal egal ist, wie es 2010 war. Und es zeigt, dass die längste Dauer im Jahr 2010 war.
 
fxsaber #:
Wenn Sie ab 2020 zuschauen wollen, können Sie das gerne tun. Ab 2023, kein Problem. Es ist nur so, dass es Ihnen manchmal egal ist, wie es 2010 war. Und es zeigt, dass die längste Dauer im Jahr 2010 war.
Ah - ich hab's kapiert. Nicht für einen Tester mit einem Experten/Strategie, sondern für ein reales Konto, auf dem verschiedene Ideen getestet wurden.

Die Festlegung eines Forward-Datums würde helfen, die Statistiken zu trennen.

 
Forester #:
Ah - ich habe den Punkt verstanden. Nicht für einen Tester mit einem Experten/Strategie, sondern für ein echtes Konto, auf dem verschiedene Ideen getestet wurden.

Ich selbst würde es nur für einen Tester verwenden. Echte Drawdowns sind überhaupt nicht interessant.

 
Forester #:
Was ist daran falsch?

Potenziell gefährlicher Stil. Zum Beispiel werden Sie irgendwann später Ihre eigene benutzerdefinierte Datumsformatierungsfunktion schreiben wollen, und ihr Aufruf wird aus Gewohnheit in eine super-duper lange Zeile geschrieben werden:

Print("From " + TimeToString(From[i], TIME_DATE) + " MaxLengthDD = " + (string)(MaxLengthDD(BeginDD, EndDD, From[i]) / (25 * 3600)) + " days: " + Format(BeginDD) + " - " + Format(EndDD));

Aber es gibt keine Garantie, dass Format-ids nach MaxLengthDD aufgerufen wird, nur weil sie rechts unter den Summanden aufgeführt sind.

Im Prinzip hat ein einzeiliger, superlanger Datensatz negative Seiten: Er ist schwer zu lesen und zu verstehen (tatsächlich ist es schwierig, das Parsen eines Ausdrucks im Kopf zu wiederholen, wie es ein Compiler tut, aber ein Mensch ist schließlich kein Compiler), er ist schwer zu debuggen. Und ein solcher kompakter Datensatz bringt auch keinen Leistungsgewinn mit sich.

 

Super Bibliothek! Vielen Dank an den Autor!

Verbesserungsvorschläge:
- interaktives Diagramm ausblenden (oder einen anderen Mechanismus dafür hinzufügen), wenn man erneut auf das Diagramm klickt,
- Quelltext in UTF-8 speichern, so dass er von GitHub normal gelesen werden kann (dies ist ein einmaliger Vorgang, der nichts bedroht, aber die Bequemlichkeit erhöht)
- Dateinamen auf verbotene Zeichen prüfen (\ / / : * ? ? " < > | : :) und ersetze sie durch etwas Neutrales (z.B. -)
- füge einen Parameter hinzu, um Berichte im gemeinsamen Ordner der Terminals zu speichern, so dass man sie nicht in den Ordnern der Agenten suchen muss.


Nochmals vielen Dank, ein sehr praktisches Tool!

 
Andrey Khatimlianskii Ordner der Terminals zu speichern, damit sie nicht in den Ordnern der Agenten gesucht werden müssen


Nochmals vielen Dank, ein sehr praktisches Tool!

Ich habe alles erledigt.
Dem Aufruf
wurden 2 neue Parameter hinzugefügt 
void QuickReport(string file_name, bool is_open_file_in_browser=true, int virtual_number=0, bool hide_account_and_name=false, bool common_path=false, bool fileANSI=true){...}
common_path - Speichern im gemeinsamen Terminal-Ordner. Um zu verhindern, dass Dateien während der Optimierung von einem anderen Agenten überschrieben werden, wurde die Agentennummer (3000, 3001,...) zu den Dateinamen hinzugefügt. Beim Speichern im Tester-Ordner (false) werden sie im Ordner des Agenten gespeichert, der die Berechnungen durchgeführt hat.
fileANSI - Speichern in ANSI-Kodierung oder in UNICODE. Die Größe von UNICODE-Dateien ist 2-mal größer und ihre Verarbeitung dauert länger. Wenn Sie also viele Daten hochladen, z. B. 1 GB, ist es wirtschaftlicher, ANSI zu verwenden. UNICODE wird für die Kompatibilität mit Diensten von Drittanbietern hinzugefügt, falls Sie es benötigen.

Eine Zeichenprüfung und eine Schaltfläche zum Ausblenden wurden ebenfalls hinzugefügt, aber ich habe sie nicht beschrieben.
 
Forester #:
2 neue Parameter für den Aufruf hinzugefügt
Auf diese Weise werden neue Parameter hinzugefügt. Deshalb ist es besser, die Signatur einmal zu schreiben, wobei die Struktur der Bedingungen eingegeben wird. Dann wird sich die Signatur nicht ändern. Genau das habe ich in Report getan.
 
fxsaber #:
Auf diese Weise werden neue Parameter hinzugefügt. Deshalb ist es besser, die Signatur einmal zu schreiben, wobei die Struktur der Bedingungen eingegeben wird. Dann wird sich die Signatur nicht ändern. So habe ich es in Report gemacht.
Vielleicht ist es besser. Aber es ist notwendig, das derzeitige Schema der Aufrufe für die Kompatibilität mit fertigen Programmen, die die Bibliothek verwenden, beizubehalten, damit nicht jemand den Code bearbeiten muss.
 
Forester #:
Wahrscheinlich besser. Aber es ist schon notwendig, das derzeitige Aufrufschema beizubehalten, um die Kompatibilität mit fertigen Programmen, die die Bibliothek verwenden, zu gewährleisten, damit nicht jemand den Code bearbeiten muss.

Das Überladen wird helfen.

12345678910
Neuer Kommentar