Typische Fehler und wie man damit umgeht, wenn man mit dem Handelsumfeld zu tun hat - Seite 6
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
Wir haben bereits darüber gesprochen. Es wird nicht universell sein, denn der eine braucht das eine, der andere das andere.
Ich fordere eine Rückkehr zur Realität. Und wenn eine Ungewissheit in Form eines Marktauftrags besteht, dann wartet man entweder auf dessen Ergebnis und gibt zurück, was bereits geschehen ist, oder man lässt das Programm entscheiden, wie es damit umgehen soll. Aber sicher nicht, um auf gut Glück eine Menge zurückzugeben.
Das ist keine Gegenleistung, so ist es nun einmal. Es gibt zwei Positionen, die vollständig geändert werden können, und eine, die eingefroren ist (keine Änderung). Insgesamt gibt es drei Stellen. Das passt gut zu der MT4-Logik, die Sie als Referenz genommen haben.
Hätte der MC einen normalen Synchronbetrieb durchgeführt, hätten sich solche Fragen gar nicht gestellt.
Außerdem hat fxsaber erklärt, warum er es so macht, wie er es macht, und warum er mit meiner Logik nicht zufrieden ist.
Forum zum Thema Handel, automatisierte Handelssysteme und Testen von Handelsstrategien
Typische Fehler und deren Behebung bei der Arbeit mit einer Handelsumgebung
fxsaber, 2018.02.24 16:25
Ich zeige Ihnen sogar, wie solche stornierten Marktaufträge aussehen
Nur gibt es keinen Fehler.
Dieses Beispiel erwies sich als viel cooler. Ein vom Broker selbst platzierter TP wurde kodiert! Und fast sofort (ich habe 115 ms gewartet - anscheinend war es ein Fehler des MT5), nachdem die Nachbestellung geschlossen wurde, setzte der Broker einen weiteren TP, der ausgeführt wurde. Die Kommentare zu den Aufträgen sind auf dem Screenshot nicht zu sehen. Die grüne Farbe istORDER_REASON_TP. Dementsprechend hat der abgelehnte Auftrag sogar eine ORDER_POSITION_ID.
Wenn die MCs einen normalen Synchronbetrieb durchführen würden, gäbe es überhaupt keine solchen Fragen.
Ein solcher OrderSend kann vom Programmierer selbst geschrieben werden. Wenn ich synchrones OrderSend verwende, ist dies die Lösung, die ich verwende.
Es sollte klar sein, dass die MCs eine Auszeit bekommen können, wenn sie es selbst schreiben. Logischerweise ist der Verwalter nicht für Marktaufträge verantwortlich, die an ein Drittsystem gesendet werden.
Ich habe mich sehr bemüht, konnte aber immer noch nicht herausfinden, wo 2 + 1 != 3 wichtig ist.
ZZZ gibt es auch eine asynchrone Variante. Und dort ist es durchaus möglich, auf einen Marktauftrag zu stoßen. Eine solche Positionszählfunktion wäre also auch dann relevant, wenn die MCs einen "normalen Synchronbetrieb" durchführen würden.
Dieser OrderSend kann vom Programmierer selbst geschrieben werden. Wenn ich eine synchrone Variante von OrderSend verwende, ist dies die Lösung, die ich verwende.
Es sollte jedoch klar sein, dass die MCs eine Zeitüberschreitung bekommen könnten, wenn sie selbst eine solche Lösung schreiben. Logischerweise ist der Verwalter nicht für Marktaufträge verantwortlich, die an ein Drittsystem gesendet werden.
Ich habe mich sehr bemüht, konnte aber immer noch nicht herausfinden, wo 2 + 1 != 3 wichtig ist.
Nein, nicht so. In Ihrem Fall: 2 + 1 - 1 = 3
Mir ist klar, dass wir unterschiedliche Berechnungsmethoden haben. Wahrscheinlich sollte ich nicht weitermachen. Aber es würde sich lohnen, das Buy More zu beeinflussen, damit es aufhört, Code mit Fehlern zu veröffentlichen.
Mir ist klar, dass wir unterschiedliche Berechnungsmethoden haben. Wahrscheinlich sollte ich nicht weitermachen. Aber ich denke, dass es sich lohnen würde, KB zu beeinflussen, damit er aufhört, Code mit Fehlern zu veröffentlichen.
Ich habe mich sehr bemüht, aber ich kann immer noch nicht herausfinden, wo es wichtig ist, dass 2 + 1 != 3 ist.
wenn die Strategie eine sofortige Reaktion auf eine offene Position impliziert. In diesem Fall kann die Regex die Logik durchbrechen.
In den allermeisten Fällen wird jede Buchführung (sowohl der Auftrag als Position als auch der Auftrag als nicht-operativer Zwischenzustand) die Probleme beseitigen.
Ein solcher OrderSend kann vom Programmierer selbst geschrieben werden.
seltsame logik, ich kann das terminal auch so schreiben. nach mt4 sieht es so aus, als würde man die probleme in den kopf des programmierers verlagern. und so viele dinge.
wenn die Strategie eine sofortige Reaktion auf eine offene Position vorsieht. In diesem Fall kann die Umleitung die Logik durchbrechen.
Ich fürchte, das ist eine krumme Logik. Aber ich könnte natürlich auch falsch liegen. Es wäre interessant, die Logik zu erfahren.
seltsame logik, ich kann das terminal auch so schreiben. nach mt4 sieht es so aus, als würde man die probleme in den kopf des programmierers verlagern. und so weiter mit vielen dingen.
Ich denke, es ist immer noch eine Frage der uninformierten oder schwachen Dokumentation. Ich denke, wenn dort alles gut erklärt wäre, gäbe es weniger Fehler und solche Gespräche. Aber dafür ist dieses Forum ja wohl da. Denn es ist offensichtlich, dass es unmöglich ist, alles in der Dokumentation zu berücksichtigen.
ZZY Der Quellcode meiner vorgefertigten Lösung wurde in den öffentlichen Bereich gestellt.