AUFTRAG_POSITION_ID - Seite 21

Neuer Kommentar
 
Mikalas:

...

Aber ich wollte es durchAufträgeimplementieren(es kommt vor, dass ein teilweise ausgeführter Auftrag für ein paar oder drei Tage "steht"),

...

Michael, du hattest Recht! Warum haben Sie es nicht getan? Sie müssen sich darüber im Klaren sein, dass Sie bei der Bearbeitung von Nettopositionen früher oder später auf die Analyse der darin enthaltenen Aufträge nicht verzichten können. Das sage ich Ihnen als jemand, der sich monatelang mit dieser Frage beschäftigt hat und diesen Fehler schon oft gemacht hat:) Und wenn Sie mehr als einen Handelsroboter haben, müssen Sie den Beitrag jedes Roboters zur gemeinsamen Position berücksichtigen, und auch hier geht es nicht ohne Aufträge. Alle erforderlichen Informationen sind in den Aufträgen und in den darauf basierenden Geschäften vorhanden, und die Zusammenführung der Geschäfte zu einer einzigen Nettoposition löscht diese Informationen unwiderruflich.

Wenn Sie Ihr System jedoch auf die Analyse von Aufträgen und Geschäften stützen, sollten Sie die teilweise Ausführung von Aufträgen in Betracht ziehen. Zu diesem Zweck sollten Sie eine virtuelle Version des Auftrags erstellen und das Eintreffen neuer Geschäfte kontrollieren. Mein Algorithmus sieht folgendermaßen aus:

1. Es wurde ein neues Geschäft empfangen (der Zähler HistoryDealsTotal() hat sich geändert).

2. Wenn dieses Geschäft durch einen Auftrag ausgelöst wird, legen wir einen neuen Auftrag mit einem einzelnen Geschäft an (COrder* order = new Order(deal)).

3. Als Nächstes suchen wir in unserer Liste der bereits bestehenden virtuellen Aufträge nach einem Auftrag mit der gleichen Kennung. Wenn ein solcher Auftrag gefunden wird, werden die Geschäfte des erstellten Auftrags mit den Geschäften des gefundenen Auftrags zusammengeführt und seine Eigenschaften aktualisiert, und der erstellte Auftrag wird gelöscht. Wenn derselbe Auftrag noch nicht in der Liste enthalten ist, fügen wir ihn einfach der Liste hinzu.

Auf diese Weise wird das System vollständig deterministisch. Bei jedem neuen Handel ändert unsere virtuelle Order ihren Status, und es spielt keine Rolle, ob die tatsächliche Order zur Ausführung ansteht oder bereits in die Historie verschoben wurde, wir werden sie in unserem System immer im tatsächlich ausgeführten Volumen sehen.

 
Contender:
Und wenn wir die Position schließen und der nicht ausgeführte Teil des Auftrags nicht entfernt wird, wird eine andere Position eröffnet (oder geändert)?

Gute Frage!

Wenn der Auftrag aktiv ist, steht er nicht in der Historie (dies wurde sicherheitshalber überprüft),

Und natürlich kann ein aktiver Auftrag eine weitere Position eröffnen, aber wenn

wird er teilweise wieder ausgeführt, wir weisen ihm keine ORDER_POSITION_ID zu.

Mit anderenWorten:ORDER_POSITION_ID ist nur in der Historie zu sehen.

 
C-4:

Ja, das kommt an der Börse vor, und diese Situationen müssen berücksichtigt werden. Dies ist einer der grundlegenden Nachteile von Limitaufträgen.

In Ihrem Beispiel denke ich, dass wir sie ersetzen können:

An:

Alle Kauf- und Verkaufstransaktionen werden durch eine Art von Auftrag eingeleitet.

Nein, das kann man nicht, denn die Geschäfte werden zwar abgewickelt, haben aber kein Ticket (oder eher Ticket = 0),

aber sie haben einen Preis und einen Typ (BUY und SELL) und natürlich IN und OUT :(

 
C-4:

Mikhail, und das zu Recht! Warum haben Sie es nicht umgesetzt? Sie müssen sich darüber im Klaren sein, dass Sie bei der Bearbeitung von Nettopositionen früher oder später auf die Analyse der darin enthaltenen Aufträge nicht verzichten können. Das sage ich Ihnen als jemand, der sich monatelang mit dieser Frage beschäftigt hat und diesen Fehler schon oft gemacht hat:) Wenn Sie mehr als einen Handelsroboter haben, müssen Sie außerdem den Gewinn jedes Roboters in der Gesamtposition berücksichtigen, und auch hier können Sie nicht auf Aufträge verzichten. Alle notwendigen Informationen sind in den Aufträgen und den darauf basierenden Geschäften enthalten, und durch die Zuordnung der Geschäfte zu einer einzigen Nettoposition werden die Informationen unwiderruflich gelöscht.

Wenn Sie Ihr System jedoch auf die Analyse von Aufträgen und Geschäften stützen, sollten Sie die teilweise Ausführung von Aufträgen in Betracht ziehen. Zu diesem Zweck sollten Sie eine virtuelle Version des Auftrags erstellen und das Eintreffen neuer Geschäfte kontrollieren. Mein Algorithmus sieht folgendermaßen aus:

1. Es wurde ein neues Geschäft empfangen (der Zähler HistoryDealsTotal() hat sich geändert).

2. Wenn dieses Geschäft durch einen Auftrag ausgelöst wird, legen wir einen neuen Auftrag mit einem einzelnen Geschäft an (COrder* order = new Order(deal)).

3. Als Nächstes suchen wir in unserer Liste der bereits bestehenden virtuellen Aufträge nach einem Auftrag mit der gleichen Kennung. Wenn ein solcher Auftrag gefunden wird, werden die Geschäfte des erstellten Auftrags mit den Geschäften des gefundenen Auftrags zusammengeführt und seine Eigenschaften aktualisiert, und der erstellte Auftrag wird gelöscht. Wenn derselbe Auftrag noch nicht in der Liste enthalten ist, fügen wir ihn einfach der Liste hinzu.

Auf diese Weise wird das System vollständig deterministisch. Der Status unserer virtuellen Order ändert sich mit jedem neuen Geschäft, und es spielt keine Rolle, ob die tatsächliche Order zur Ausführung ansteht oder bereits in die Historie verschoben wurde, wir sehen sie in unserem System immer im tatsächlich ausgeführten Volumen.

Vasiliy, ich habe alles implementiert (nicht so wie du, aber auch nicht schlecht), ich wollte nur die Suchzeit reduzieren...
 
Serj_Che:

Problem gelöst, Beziehungen geklärt )

Ich habe eine verwandte Frage:

Es ist sehr unbequem, einen Auftrag nach Ticket auszuwählen, um seine Eigenschaften zu sehen, denn es spielt keine Rolle, wo sich der Auftrag in der Historie oder auf dem Markt befindet, und das Ticket wird sich nicht ändern.

Wir müssen also sowohl hier als auch dort nach der Ordnung suchen.

Wäre es nicht einfacher, es wie in MT4 zu machen: Wenn wir einen Auftrag auswählen, ist es egal, wo er sich befindet.

Ich habe es in der MT4-Hilfe gelesen:

Was halten Sie davon?

P.S. Ich hoffe, Mihail hat nichts dagegen, diesen Thread fortzusetzen, um nicht noch mehr neue zu produzieren?


Mikalas:

C-4, es ist sehr schön, dass die Diskussion konstruktiv war!

Ich brauche also den "Netto"-Preis der Position, um zu wissen, wie hoch mein Gewinn ist (z. B. in einem Monat).

...

In der Funktion (ich verwende sie jetzt):

...

Relevante Frage, in der Regel die MetaTrader5 API ist wirklich ziemlich niedrig Ebene. Aber ... Der Handel an der Börse hat viele Nuancen: Ausführung von Aufträgen durch mehrere Geschäfte, Zusammenführung von Geschäften zu einer Nettoposition und deren Übertragung durch Clearing, eine Fülle von Maklertransaktionen und so weiter und so fort. MetaTrader5 API (und MT5 selbst) ist also so, wie es jedes Börsenterminal sein sollte.

Eine andere Sache ist, dass seine API in einen High-Level-Wrapper, der in MQL5 geschrieben ist, eingepackt werden kann und dadurch die Low-Level-Funktionen von MT5 nutzen kann. Wenn ich den Wrapper hätte, würde Mihails Aufgabe der Gewinnberechnung wie folgt aussehen

for(int i = 0; i < TransactionsTotal(); i++)
{
    if(TransactionSelect(i, SELECT_BY_POS, MODE_TRADES))
    {
         ENUM_TRANS_TYPE trans_type = TransactionType();
         if(trans_type == TRANS_HEDGE_POSITION)
         {
              if(HedgePositionGetInteger(HEDGE_POSITION_MAGIC) != myMagic)continue;  // Работаем только со своими позициями.
              if(HedgePositionGetString(HEDGE_POSITION_SYMBOL) != Symbol())continue; // Работаем только с позициями на своем инструменте.
              double profit = HedgePositionGetDouble(HEDGE_POSITION_PROFIT_POINTS); //Профит в пунктах
              double currency = HedgePositionGetDouble(HEDGE_POSITION_PROFIT_CURRENCY); //Профит в валюте депозита.
              double price_open = HedgePositionGetDouble(HEDGE_POSITION_PRICE_OPEN); //Фактическая цена открытия позиции без клирингов и пр. изменений.
              double sl = HedgePositionGetDouble(HEDGE_POSITION_SL); //Узнаем уровень стоп-лосса позиции, если он есть, если нет - вернет нормализованный 0.0.
              if(HedgeOrderSelect(ORDER_SELECTED_INIT)) //Выбираем ордер, открывающий текущую позицию.
              {
                 int deals = HedgeOrderGetInteger(HEDGE_ORDER_DEALS_TOTAL); //Получаем количество сделок, открывающего ордера.
              }
              // Ну и так далее...
         }   
    }
}
 
Mikalas:

Nein, das kann man nicht, denn beim Clearing werden zwar Geschäfte getätigt, aber sie haben kein Ticket (oder eher Ticket = 0),

sondern haben einen Preis und einen Typ (BUY und SELL) und natürlich IN und OUT :(

Scheiße, richtig:

Dann Traurigkeit für Sie.

 
Mikalas:
Vasiliy, ich habe alles implementiert (nicht so wie du, aber auch nicht schlecht), ich wollte nur die Suchzeit reduzieren...
Übrigens, wie gehen Sie mit multidirektionalen Einträgen Ihrer Roboter um? Schließlich kann der Markteintritt des einen Expert Advisors der Ausstieg eines anderen Roboters sein.
 
Mikalas:

Gute Frage!

Wenn der Auftrag aktiv ist, steht er nicht in der Historie (dies wurde sicherheitshalber überprüft),

Und natürlich kann ein aktiver Auftrag eine weitere Position eröffnen, aber wenn

wird sie teilweise wieder ausgeführt, wir weisen ihr keine ORDER_POSITION_ID zu.

Mit anderenWorten: DieORDER_POSITION_ID ist nur in der Historie zu sehen.

Hier gibt es ein weiteres Problem. Ein Teil der durch diesen Auftrag ausgeführten Geschäfte gehört zu der einen Position, der andere Teil gehört bereits zu der anderen, neuen Position. Dann stellt sich die Frage, welche Positionskennung ihr zugewiesen wird, wenn sie schließlich in die Geschichte eingeht.
 
C-4:
Übrigens, wie gehen Sie mit multidirektionalen Einträgen Ihrer Roboter um? Schließlich kann der Einstieg eines Expert Advisors in den Markt ein Ausstieg aus der Position eines anderen Roboters sein.
Bei mir gibt es keine Überschneidungen.
 
C-4:
Das Problem ist hier ein anderes. Ein Teil der ausgeführten Geschäfte dieses Auftrags wird zu einer Position gehören, der andere Teil wird bereits zu einer anderen, neuen Position gehören. Dann stellt sich die Frage, welche Positions-ID ihr zugewiesen wird, wenn sie früher oder später in die Geschichte eingeht.

Ein vollständig ausgeführter Auftrag erhält die ID der Position, die er eröffnet oder geändert hat.

Diese wird aber nur in der Historie verfügbar sein (ID).

1...1415161718192021
Neuer Kommentar
Grund der Beschwerde: