Organisation des Auftragszyklus - Seite 2
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
Denn der Preis wird sich bewegen, und bei jedem neuen Aufruf von OnTick wird die Bedingung für eine neue Änderung der gleichen, in der Liste an erster Stelle stehenden, Reihenfolge erfüllt sein. Vor allem, wenn die Änderung nur 5 Sekunden dauert ;)
Auch hier wird die Frage der Relevanz angesprochen. Eine Bestellung ist immer auf dem neuesten Stand. Die anderen werden auf dem neuesten Stand sein. Bei Ihrer Variante hingegen sind alle Aufträge nicht auf dem neuesten Stand.
Ein solches "Backbone" würde die Logik eines EA, der mit mehr als einem Auftrag arbeitet, durchbrechen.
Welchen Sinn hätte es, wenn es den Systemen mit einem Auftrag keinen Vorteil brächte und die anderen verderben würde?
Ich würde gerne verstehen, was Sie meinen, aber ich kann es nicht. Ich sehe kein Problem mit dem Grundsatz "Wenn die Wartezeit abgelaufen ist, aktualisiere die Handelsumgebung".
Es ist richtig, vor der Bearbeitung von Aufträgen nach Volumen und/oder Abstand zum Preis zu sortieren. Wir sollten aber nicht davon ausgehen, dass jeder, der den Code aus dem Forum kopiert, ihn auch umsetzt.
In diesem Sinne ist mein Code sicherer.
Nun, es wurde nicht für Neulinge geschrieben. Sie und ich haben es hier sehr gut besprochen - kein Wasser.
Auch hier stellt sich die Frage der Relevanz. Eine Bestellung ist immer auf dem neuesten Stand. Die anderen werden nach Möglichkeit auf dem neuesten Stand sein. Sie haben die Möglichkeit, dass alle Bestellungen nicht auf dem neuesten Stand sind.
Tatsächlich - um wie viel?
Ich bin froh, dass ich verstehe, was Sie meinen, aber es funktioniert nicht. Ich sehe kein Problem mit dem Prinzip "Wenn die Wartezeit abgelaufen ist, aktualisiere die Handelsumgebung".
Ihr Algorithmus ist auf die erste Reihenfolge in der Liste fixiert, das ist alles.
In manchen Situationen kann sich dies nachteilig auf das System auswirken (ich habe es in der Praxis erlebt).
Tatsächlich - um wie viel?
In meiner Variante wären beide SLs bei 1,2375 oder schlimmstenfalls bei 1,2374 geändert worden. Fazit: +30 Pips bei beiden Aufträgen.
Bei jedem Schritt in Ihrem Beispiel sollte der TS wissen, wo seine Aufträge sein sollten, ohne dass ein Handelsauftrag vorliegt. D.h. der TS kann nicht in irgendeiner Weise daran gebunden werden, wo seine Aufträge jetzt sind. Es geht nur darum, zu berechnen, wo sie stehen sollten, und die Handelsumgebung mit dem zu synchronisieren, was es durch Handelsaufträge berechnet hat.
In Ihrem Beispiel hängt das Ergebnis des TS jedoch davon ab, ob OnTick den Höchstkurs erreicht hat oder nicht. Und die richtige TS sollte genau dem entsprechen. Sie sieht, dass ein solcher Kurs zustande gekommen ist (auch wenn der OnTick mit ihm verpasst wurde), und daher sollten ihre SLs entsprechend platziert werden. Und die Synchronisierung wird zu 100 % funktionieren.
Und ich verstehe nicht, warum Sie immer wieder sagen, dass die zweite stillsteht. Auch ohne Synchronisationslogik wird sie auf dieselbe Weise wie in Ihrer Variante geändert. Es ist nicht so, dass OnTick beim Ereignis NewTick aufgerufen wird, sondern als normale interne Funktion.
Bei jedem Schritt in Ihrem Beispiel muss der TS wissen, wo seine Aufträge ohne einen Handelsauftrag stehen sollen. Das heißt, der TS kann in keiner Weise mit dem aktuellen Stand der Aufträge verknüpft werden. Es geht nur darum, zu berechnen, wo sie stehen sollten, und die Handelsumgebung mit dem zu synchronisieren, was es durch Handelsaufträge berechnet hat.
Ja, sie weiß es. Aber sie hat keine Zeit, sie zu synchronisieren - während eine Änderung durchläuft, bewegt sich der Preis weiter und eine neue berechnete Bedingung sagt ihr, dass sie die erste Bestellung erneut ändern muss. Und das passiert ständig.
In Ihrem Beispiel hängt das Ergebnis von TC davon ab, ob OnTick den Höchstkurs erreicht hat oder nicht. Und die richtige TS sollte genau davor liegen. Sie sieht, dass ein solcher Preis war (auch wenn der OnTick damit verpasst wurde), was bedeutet, dass ihre SLs entsprechend platziert werden sollten. Und die Synchronisierung wird zu 100 % funktionieren.
Das ist nicht der Fall (in dem Beispiel wurde keine SL-Stufe berechnet).
Und die Synchronisierung wird die Aufgabe nicht erfüllen, da sie keine Zeit hat (siehe oben).
Und ich verstehe nicht, warum Sie immer wieder sagen, dass die zweite stillsteht. Auch ohne Synchronisationslogik wird sie auf dieselbe Weise wie in Ihrer Variante geändert. Es ist nicht so, dass OnTick beim Ereignis NewTick aufgerufen wird, sondern als normale interne Funktion.
Wie immer habe ich es verstanden.
Der Preis hat sich jedoch bereits geändert, während die Änderung im Gange war, und der erzwungene Aufruf von OnTick arbeitet bereits mit dem neuen Preis, während der zweite Auftrag auf dem ursprünglichen Niveau bleibt.
Es liegt kein Fehler vor. Vielleicht zu spezifisch für Ihre (aber wieder ganz real, aus dem Leben) Situation.
Sie weiß es, sie weiß es. Aber er hat keine Zeit, sich zu synchronisieren - während eine Änderung durchläuft, bewegt sich der Preis weiter, und die neue berechnete Bedingung veranlasst ihn, den ersten Auftrag erneut zu ändern. Und das passiert ständig.
Das Beispiel, das Sie sich ausgedacht haben, bringt uns in dieser Logik keine zusätzlichen Verluste. Lassen Sie mich Ihnen ein Beispiel geben.
Nehmen wir an, wir verfolgen BuyLimits nach der Aufwärtsbewegung, um beim notwendigen Pullback zu eröffnen. Fast Lucky-TC. Wenn wir jedes Mal einen Berg von Limits mitschleppen, werden wir keinen Pullback mit Ihrer Option erwischen.
Es ist schon seltsam, Handelsaufträge auf der Grundlage einer veralteten Handelsumgebung zu erteilen. Aber Sie verteidigen (wie ich) hartnäckig eine andere Sichtweise.
Nun, es ist schon seltsam, Handelsaufträge auf der Grundlage eines veralteten Handelsumfelds zu erteilen. Aber Sie verteidigen (wie ich) hartnäckig eine andere Sichtweise.
Man muss sich für das kleinere Übel entscheiden.
Das Beispiel mit dem hinter dem Kurs liegenden Limit ist natürlich besser in der Variante "1 EA = 1 Order in jede Richtung" umzusetzen.
Im Allgemeinen ist es jedoch besser, alle Aufträge unter Kontrolle zu halten.
Aber im Allgemeinen ist es richtiger, alle Ihre Aufträge unter Kontrolle zu halten.
Das heißt, Sie sind nicht damit einverstanden, dass der TS nur mit dem aktuellen Handelsumfeld arbeiten soll.
Das heißt, Sie sind nicht damit einverstanden, dass der TS nur mit dem aktuellen Handelsumfeld arbeiten soll.
Wenn Sie dafür die Kontrolle über alle TK-Aufträge opfern müssen - unbedingt.
Stellen Sie sich vor: Sie haben eine Flotte von vier Lastwagen. Jeder von ihnen befördert eine wertvolle Fracht von A nach B. Sie müssen die Route überwachen.
Was wäre Ihnen lieber: jede Minute mit einem von ihnen in Kontakt zu sein oder alle 2 Minuten mit allen?
Im zweiten Fall ist die Verspätung etwas größer, und alle vier müssen möglicherweise einen kleinen Umweg nehmen, wenn sie nicht rechtzeitig weitergeleitet werden. Aber insgesamt wird es für das Unternehmen besser sein, als einen Lkw zu behalten und die anderen drei zu verlieren.
Wenn Sie dafür die Kontrolle über alle TK-Aufträge opfern müssen, unbedingt.
Stellen Sie sich vor: Sie haben eine Flotte von 4 Lastwagen. Jeder von ihnen befördert eine wertvolle Fracht von A nach B. Sie müssen die Route kontrollieren.
Würden Sie lieber jede Minute mit einem von ihnen in Kontakt sein oder alle 2 Minuten mit allen?
Im zweiten Fall ist die Verspätung etwas größer, und alle vier müssen möglicherweise einen kleinen Umweg machen, wenn Sie sie nicht rechtzeitig weiterleiten können. Aber insgesamt ist es für das Geschäft besser, als einen Lkw auszugeben und die anderen drei zu verlieren.
+1.
Vielleicht wäre die neue Idee nicht mit dem OOP-Ansatz entstanden, bei dem eine Schleifenanalogie mit Order Brute Force in einer managerähnlichen Entität versteckt ist, die, anstatt OrderModify direkt aufzurufen, einen Änderungsbefehl (mit allen Parametern) erzeugt und in eine Warteschlange stellt, die dann abgearbeitet wird. Die Idee besteht darin, die Verantwortung (die in diesem Code in eine einzige Schleife gezwängt ist) zwischen einer Entität, die die Umgebung analysiert, und einer Entität, die auf der Grundlage der Analyse Aktionen durchführt, zu teilen.
Vielleicht würde diese Idee bei einem OOP-Ansatz nicht auftauchen, wenn ein Analogon der Schleife mit der Auftragssuche in einer Entität wie dem Manager verborgen ist, der, anstatt OrderModify direkt aufzurufen, einen Änderungsbefehl (mit allen Parametern) erzeugt und ihn in eine Warteschlange stellt, die dann verarbeitet wird. Die Idee ist, die Verantwortung (die in diesem Code in eine einzige Schleife gezwängt ist) zwischen einem Objekt der Analyse der Umgebung und einem Objekt der Durchführung von Aktionen auf der Grundlage der Analyse zu teilen.
Die einzige Möglichkeit, eine solche Situation zu vermeiden, ist die Verwendung asynchroner Aufträge.
Andernfalls gäbe es immer noch eine Schleife über die Liste der auszuführenden Befehle, die in Wirklichkeit eine Schleife über Aufträge ist.
Nur in einer Warteschlangensituation müssten Sie noch Vorkehrungen treffen, um einen älteren nicht ausgeführten Auftrag, der sich auf einen Auftrag bezieht, durch einen neueren zu ersetzen. Andernfalls könnte die Warteschlange überlaufen, und die Aufträge würden aus der Warteschlange herausgeschickt werden - das wäre überflüssig.