Organisation des Auftragszyklus - Seite 4
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
Das wird sie nicht sein, denn sie ist nicht stark.
Zunächst wird der TS für den Tester geschrieben, wo die Handelsbedingungen ideal sind. Wenn alles in Ordnung ist, versuchen sie, die Live-Version so zu schreiben, dass sie dem, was sie im Tester sehen, so nahe wie möglich kommt. Alle anderen Ansätze, die TS zu schreiben, sind die Hit-or-Miss, nicht die Algorithmisierung der Idee.
Es stellt sich also die grundsätzliche Frage, welche Kampfsituation für einen Tester am ehesten in Frage kommt. Ich habe meine Meinung geäußert (und ein Beispiel genannt), ich habe Ihre gehört.
Ich stehe vor der Aufgabe, die Handelslogik eines Expert Advisors vom Tick-Test im Strategietester (MT4) auf seine Arbeit auf einem realen Konto zu übertragen.
Meine Argumentation:
Im Test funktioniert der Expert Advisor nicht nur unter idealen Handelsbedingungen, sondern tatsächlich in einem anderen Modus - in Echtzeit, d.h. er hat Zeit, TS zu berechnen, eine Order zu senden und die Antwort in einem einzigen Tick zu erhalten, aber das ist im realen Handel nicht so. Es hat den Anschein, als hätten wir zwei verschiedene Roboter - einen mit Echtzeit und einen ohne Zeit. Wenn wir einen Auftrag (auch nur einen!) an ein reales Konto senden/ändern = Ping + Ausführungszeit, usw. = bestenfalls 100-500ms, und während dieser Zeit gehen Ticks, die gezählt werden müssen - und wir stehen, warten... und dann kommen wir zufällig in den Fluss (wohin sich der Preis in dieser Zeit relativ zu unseren Tick-Durchschnitten entwickelt hat, wissen wir nicht. + wir müssen einige der schnellsten und meist wichtigsten Ticks verpasst haben). Es kann also sein, dass von der Strategie, die wir im Tester ausgeführt haben, nichts mehr übrig ist.
Nach reiflicher Überlegung bin ich daher zu folgendem Schluss gekommen:
Nach reiflicher Überlegung bin ich also zu folgendem Schluss gekommen:
Ja, ich verwende den gleichen Ansatz - eine Art interner Idealtester mit seinen eigenen offenen Aufträgen und einem Kopierer, der versucht, diese virtuellen Aufträge zu realisieren. Mit dieser Regelung lassen sich viele schwerwiegende Probleme ganz einfach umgehen.
Im MT5 ist es einfacher, weil wir dort die Tick-Historie abfragen können. Und Sie können sie für mehrere Symbole anfordern.
Es geht nicht um Zeit, es geht um Logik (über Zeit - das ist ein anderes Thema ;-) ). Ihre Logik (und meine Logik, denn ich stimme mit allem überein, auch mit der Autoanalogie) besteht darin, die Umweltanalyse "auf einen Schlag und in einem Stück" durchzuführen, statt stückweise. Die Verarbeitung etwaiger Nebeneffekte wird auf den nächsten Lauf verschoben, da diese Effekte in das neue Handelsumfeld eingebaut werden.
Nun, wenn es keine Zeitkorrektur gäbe, wären beide Logiken (meine und die von fxsaber) identisch - alle Aufträge würden bei jedem Tick abgewickelt werden, auch nach mehreren Fehlern.
Das Ziel besteht darin, die Realität mit einer nicht sofortigen Ausführung dem idealen Modell anzunähern, das bei der Prüfung ermittelt wurde.
Ja, ich verwende den gleichen Ansatz - eine Art interner Idealtester mit seinen offenen Aufträgen und einem Kopierer, der versucht, diese virtuellen Aufträge zu realisieren.
Wenn Sie Ihren Ansatz verwirklichen (in einer Schleife, die beim ersten Auftrag verbleibt, bis er erfolgreich mit der Realität synchronisiert ist), könnten Sie auf das gleiche Problem stoßen, dass die übrigen Aufträge aus dem Blickfeld geraten (oder einfach später verarbeitet werden). Aber hier geht es um das gleiche, angeblich abgeschlossene Thema).
Wenn Sie Ihren Ansatz verwirklichen (in einer Schleife, die beim ersten Auftrag verbleibt, bis er erfolgreich mit der Realität synchronisiert ist), könnten Sie auf das gleiche Problem stoßen, dass die übrigen Aufträge aus dem Blickfeld geraten (oder einfach später verarbeitet werden). Aber hier geht es um die gleiche Frage, die angeblich gelöst wurde).
So handeln wir!
Wir warten noch auf ein OOP-Beispiel. Und ich sehe es immer noch als das gleiche Rückgrat in Form einer Schleife. Die Logik wird sich nicht ändern, denn zunächst wird es darum gehen, festzustellen, was geändert werden muss, und dann darum, die bereits getroffenen Entscheidungen zu überprüfen.
Ich werde kein Beispiel speziell für diese Aufgabe schreiben. Sie können aber ein vereinfachtes Konzept des Ansatzes in meinem Blog sehen. Dort wird die Warteschlange nicht eingehend analysiert, sondern nur auf Leere geprüft. Wer möchte, kann sie verbessern.
Wenn wir mit Logik die Aufgabe meinen, "einen Stapel von Aufträgen aufgrund von Preisänderungen zu ändern", gibt es nur eine Aufgabe. Die Frage ist, was wichtiger ist: alle Aufträge zu ändern oder sie an die neuesten Preise anzupassen? Je nach Ihren Präferenzen wird die Logik unterschiedlich sein. Eine einfache Schleife würde gewährleisten, dass alle Aufträge geändert werden, und ich bin für diese Option. Wie bereits erwähnt, bietet das OOP eine klare Aufteilung der Aufgabe in Verantwortungsblöcke, und auf der Grundlage dieser Aufteilung ist "alle Aufträge" wichtiger als "Preisrelevanz". Das zeigt sich auch daran, dass sich die Preise ständig ändern und die Aufträge nur gelegentlich vorliegen. Sie sind viel wichtiger.
Die PLO sorgt für Klarheit bei der Aufteilung der Aufgabe in Verantwortungsblöcke, und auf der Grundlage dieser Aufteilung sind "alle Aufträge" wichtiger als "Preisrelevanz".
Aus dieser Zerlegung ergibt sich lediglich eine Trennung. Die "Preisrelevanz" wird bei diesem OOP durch das Setzen eines Platzes in der Warteschlange erreicht.
Dies ist bereits eine Art "Philosophie". Die Verarbeitung erfolgt nach Auftragswarteschlange und nicht nach Tick-Flow, wie in der Alternative vorgeschlagen. Wie auch immer, ich ziehe mich aus dieser Diskussion zurück. Alle Argumente sind bereits vorgebracht worden.
Wie auch immer, ich ziehe mich aus dieser Diskussion zurück. Alle Argumente sind bereits vorgebracht worden.
Es gibt bereits eine Tendenz, sie auf diese Weise zu beenden.
Im Folgenden werden wir ein Thema ansprechen, das nicht nur MT4, sondern auch MT5 mit anderen Plattformen betrifft. Aber die Logik wird in MQL4 geschrieben, um die Wahrnehmung zu erleichtern, also in diesem Zweig.
Meistens läuft das Rückgrat (das Fleisch eines Auftrags) der Auftragsänderung/-löschung auf die folgende Logik hinaus
Jetzt ist der Ansatz selten, aber viel richtiger
Nach dem Senden eines Handelsauftrags ändert sich die Handelsumgebung, so dass es ratsam ist, die gesamte Handelslogik des TS unmittelbar nach der Antwort des Handelsservers von Grund auf neu auszuführen.
Schleifen sind einer der gefährlichsten Programmiertricks. Sie verursacht seltsame, selten auftretende Fehler, die kaum zu analysieren sind.
Anstatt eine Schleife zu drehen, sollten Sie im Gegenteil versuchen, den Benutzer-Thread so schnell wie möglich zu beenden. Wenn Sie am Puls der Zeit bleiben wollen - analysieren Sie OnTradeTransaction im MT5. MT4 ist im Allgemeinen nicht für solche Schleifen geeignet, denn Einfachheit ist, wie man so schön sagt, schlimmer als Diebstahl.