Bibliotheken: Virtual - Seite 8

 

Nach Sprachänderungen im letzten Jahr funktionierte meine Version von Virtual nicht mehr. Ich bin zu Ihrer Version zurückgekehrt.
Aber ich habe wirklich eine Provision vermisst, die Preisänderungen berücksichtigt. Vor allem bei Kryptowährungen, bei denen sich der Preis während des Testens oft ändert.
In meiner alten Version war die Berechnung zwar genau, aber mit String-Operationen und der Abfrage von Preisen nach Instrumenten langsam. Wahrscheinlich wollten Sie es wegen dieser Langsamkeit nicht in Ihre eigene Version einbauen.

Diesmal habe ich eine einfache und schnelle Berechnung für Instrumente wie EURUSD, AUDUSD ... mit USD Einzahlungswährung und für alle Kryptowährungen, da alle auf USDT. D.h. wenn Kurswährung == Kontowährung, wird die Berechnung korrekt sein.

#define COMMISSION_TO_PRICE 2 // умножить полученную комиссию на цену, например для EURUSD *=1.12345; 1 - комиссия берется только при входе, 2 - комиссия берется 2 раза и при входе и при выходе

Die Kommission wird einfach mit dem OpenPrice oder ClosePrice multipliziert. Für Instrumente wie USDJPY oder wenn die Einzahlungswährung nicht USD(T) ist, kann die Option deaktiviert werden, da sie nicht genau sein wird (wie Ihre aktuelle Option).

#ifdef  ORDER_COMMISSION
 this.Commission = this.Lots * (ORDER_COMMISSION);
 #ifdef  COMMISSION_TO_PRICE
   this.Commission *= this.OpenPrice + (COMMISSION_TO_PRICE==2 ? this.ClosePrice : 0.0);
 #endif // COMMISSION_TO_PRICE
#endif// AUFTRAG_PROVISION

Hier ist, was ich für EURUSD erhalten habe:

DC:
Virtuell c * pro Preis
Virtuell ohne * auf Preis

Wie Sie sehen können, unterscheidet sich die Kommission mit der zusätzlichen Option nur um 18 Cent für 140 Geschäfte. Und ohne sie um 42 Dollar. Natürlich können Sie in Ihrer Variante den Durchschnittsmultiplikator nicht 4, sondern z.B. 4,305 wählen (Durchschnittsprovision für den Test), aber das müssen Sie manuell für jedes Instrument tun und neu kompilieren.

Die Änderungen sind nicht groß, ich hoffe, Sie werden diese Option in den Bibliothekscode aufnehmen wollen. Oder vielleicht fällt Ihnen etwas Universelleres ein.


Dateien:
Order.mqh  36 kb
 
Forester Einzahlungswährung USD und für alle Kryptowährungen, da alle zu USDT. D.h. wenn die Kurswährung == Kontowährung ist, wird die Berechnung korrekt sein.

In der Tat funktioniert diese Formel immer.

Commission = 0.002%; // pro Seite.

OrderCommission = (OrderOpenPrice + OrderClosePrice) * Commission * OrderLots * TickValue / TickSize;

Natürlich können Sie in Ihrer Variante den Durchschnittsmultiplikator nicht 4, sondern z.B. 4,305 wählen (Durchschnittsprovision für den Test), aber das muss dann für jedes Instrument manuell gemacht und neu kompiliert werden.

Eine andere Variante.

input double inCommission = 0;
// .....
#define  ORDER_COMMISSION inCommission // OrderCommission() = OrderLots() * (ORDER_COMMISSION)), einschließlich der dynamischen Option.

Die Änderungen sind nicht groß, ich hoffe, Sie werden diese Variante in den Bibliothekscode aufnehmen wollen. Oder vielleicht denken Sie an etwas mehr universell.

Ich stimme voll und ganz zu, dass die Änderung nützlich ist und gemacht werden sollte. Es sollte für partielle Close (OrderClose nicht für die ganze Partie) und CloseBy geprüft werden. Um das zu überprüfen, reicht es aus, ein Skript zu schreiben, in dem zwei unterschiedlich ausgerichtete Positionen auf demselben Tick geöffnet werden und ein Teilschluss und ein CloseBy-Schluss auf einmal gemacht werden. Ich bin noch nicht bereit, dies selbst zu tun. Wenn Sie ein solches Skript mit korrekten Ergebnissen vorlegen, werde ich Ihre Korrekturen schneller vornehmen.

 
fxsaber #:

In der Tat funktioniert diese Formel immer wieder.

Es ist einfacher für dich, du bist immer dabei. Ich tue es nicht immer. Zum ersten Mal seit Juli habe ich beschlossen, wieder etwas zu testen....

Über
OrderClosePrice
- es gibt wahrscheinlich einige Maklerzentren, die nur bei der Eröffnung Kommissionen nehmen - für sie ist es besser, sie nicht zu berücksichtigen. Für Pipsing wird der Unterschied gering sein, aber für große Ziele wird er spürbar sein.
 
fxsaber #:
Ich stimme voll und ganz zu, dass die Änderung nützlich ist und vorgenommen werden sollte. Es ist notwendig, auf partielle Schließung (OrderClose nicht für die ganze Partie) und CloseBy zu prüfen. Um dies zu überprüfen, reicht es aus, ein Skript zu schreiben, in dem zwei unterschiedlich ausgerichtete Positionen zum selben Tick geöffnet werden und ein Teilschluss und ein CloseBy-Schluss auf einmal durchgeführt werden. Ich bin noch nicht bereit, dies selbst zu tun. Wenn Sie mir ein solches Skript mit einem korrekten Ergebnis schicken, werde ich Ihre Korrekturen schneller vornehmen.
Ich habe das, was dort auskommentiert ist, getestet und als Arbeitsversion belassen. Aber jetzt habe ich alles vergessen. CloseBy - ich benutze es nicht, ich habe normalerweise einfachere Ideen. Ich habe auch keine Zeit dafür. Solange es Begeisterung gibt, werde ich Strategie machen.
 

Virtual erhebt eine Provision auf nicht eingehaltene Limits:


Offenbar müssen wir eine Typenprüfung durchführen
 
Forester #:

Virtual fügt den nicht ausgeführten Limits eine Provision hinzu:

Offenbar müssen wir eine Typenprüfung durchführen
#define ORDER_COMMISSION -5 // OrderCommission() = OrderLots() * (ORDER_COMMISSION)), einschließlich der dynamischen Option.
#include <fxsaber\Virtual\Virtual.mqh> // https://www.mql5.com/de/code/22577

void OnStart()
{
  if (VIRTUAL::SelectByHandle(VIRTUAL::Create()))
  {
    VIRTUAL::NewTick();
    
    OrderDelete(OrderSend(_Symbol, OP_BUYLIMIT, 1, 0.01, 0, 0, 0));
    
    Print(VIRTUAL::ToString(1));
  }
}


Ergebnis.

#2 2025.11.25 19:23:11.105 buy limit 1.00 EURGBP.pro 0.01000 0.00000 0.00000 2025.11.25 19:23:11.105 0.87715 0.00 0.00 0.00 0 - 00:00:00


Es funktioniert korrekt. Offenbar erfordern diese Bearbeitungen eine zusätzliche Prüfung.

 
fxsaber #:

Sie funktioniert korrekt. Offenbar erfordern diese Bearbeitungen eine zusätzliche Überprüfung.

Sie haben Recht.

In ToClose() habe ich die Berechnung der Provisionen außerhalb von if (this.IsPosition()){

Ich habe es korrigiert und die Datei angehängt

Dateien:
Order.mqh  37 kb
 

Ich lese das Eigenkapital und den Saldo von Virtual bei jedem Tick und erstelle ein Diagramm. Es war nicht bemerkbar, bis heute, aber heute setzen sie riesige Swaps von -66.

Das Diagramm sieht wie folgt aus.



Es sollte wie die Aufzeichnung von MT5 sein.

Der endgültige Gewinn, wie Sie sehen können, unterscheidet sich um ein paar Cent aufgrund von Rundungsfehlern bei Kommissionen (ich habe echte Kommissionen verwendet, nicht in Punkten) und Swaps (ich verstehe immer noch nicht, wie MT sie rundet - nicht über round()).

Die Summe der Swaps heute für diese Berechnung ist -5208,97. Das ist nur die Größe des Sprungs in der Grafik. Ich denke, dass die Swaps nicht während der Berechnung zu Eigenkapital und Saldo addiert werden, sondern erst am Ende, deshalb sieht es so aus.

Ich rufe VIRTUAL::CalcSwaps(...) in OnTester() auf. Kann das im virtuellen Handel gemacht werden? Es wäre bei jedem Tick zu teuer. Vielleicht sollte es am Anfang eines jeden Tages gemacht werden. Vielleicht ist es bereits programmiert und sollte durch einen Defyne aktiviert werden? Ich erinnere mich, dass ich in meiner Version Swaps für jeden Tag gemacht habe, da Sie etwas anderes haben. Wenn Sie es nicht in der Vergangenheit getan haben, kann ich Ihnen meinen Code für ein Beispiel senden.

 
Aleksei Kuznetsov #:

Vielleicht ist es bereits programmiert und sollte von einigen defyne aktiviert werden? Ich erinnere mich, dass ich in meiner Version für jeden Tag Swaps gemacht habe, so wie du es anders hast. Wenn Sie es nicht in der Vergangenheit getan haben, kann ich Ihnen meinen Code für ein Beispiel zu senden.

Das habe ich nicht. Aber für das Balance/Equity-Curve-Plotting-Problem würde ich CalcSwaps einmal in OnTester durchführen und danach die entsprechende Anpassung von Balance[]/Equity[] in einem Durchgang. Das ist superbillig und genau.

Die ganze Swap-Sache in MT5 scheint fehlerhaft zu sein, da es keine Swap-Historie gibt. Und bei einer großen Historie sind die Ergebnisse furchtbar schief, wenn Swaps berücksichtigt werden. Es kann vorkommen, dass Sie am Wochenende optimiert haben und dann die besten Läufe aus den Opt-Dateien völlig andere Werte zeigen, wenn sie an Wochentagen durchgeführt werden.

Der MT5-Tester ist jedoch kein Benchmark.