Fehler, Irrtümer, Fragen - Seite 1861

Neuer Kommentar
 

Eine weitere Frage: Ist es normal, dass es keine Flaggen gibt? Build 1585

Alpari


fxopen



FxOpenAlpariMQ
COPY_TICKS_INFO
Bid und/oder Ask		930168391679292
COPY_TICKS_TRADE
Last und Volumen		2710610102924
COPY_TICKS_ALL
alle Häkchen		364077426568182216

wenn überallCOPY_TICKS_ALL =COPY_TICKS_INFO +COPY_TICKS_TRADE

was bedeutet es dann bei Alpari?

 
kaus_bonus:

Alpari

fxopen

Sie haben keine Flossen.
 
fxsaber:
Sie haben keine Flaggen.


es ist klar, aber was wird dann hinzugefügt, umCOPY_TICKS_ALL zu erhalten?

weil sieCOPY_TICKS_TRADE=0 haben

und die Häkchen in der Geschichte mit den fehlenden Flaggen sind die unbekanntenCOPY_TICKS_TRADE ?

 
kaus_bonus:


es ist klar, aber was wird dann hinzugefügt, umCOPY_TICKS_ALL zu erhalten?

weil sieCOPY_TICKS_TRADE=0 haben

und die Ticks in der Historie mit fehlenden Flags ist unbekanntCOPY_TICKS_TRADE ?

Ich denke, es sind die krummen Hände der Makler.
 

HistoryDealGet*- und HistoryOrderGet*-Funktionen sind in Bezug auf die Leistung sehr seltsam geschrieben.

Wenn ich z. B. HistorySelect für 100K einzelne Datensätze mache. Die HistoryDealGet-Funktion benötigt als erstes Argument nicht die Anzahl der Datensätze in der History-Tabelle, sondern ein Ticket. Und die Tabelle ist nach Zeit und nicht nach Ticket sortiert. Daher durchläuft die Funktion HistoryDealGet bei jeder Ausführung als Erstes die Tabelle und sucht nach einem passenden Ticket.


Warum eine solche Verschwendung von Ressourcen! Es stellt sich heraus, dass das allererste Ticket und das jüngste Ticket mit unterschiedlicher Geschwindigkeit ausgeführt werden. Und um alle Merkmale des letzten Geschäfts zu erhalten, werden die HistoryDealGet-Funktionen jedes Mal die gesamte Tabelle durchlaufen.


Warum sollte man es nicht normal machen?

long HistoryDealGetInteger( const int index, const ENUM_ORDER_PROPERTY_INTEGER  property_id ); // номер сделки, а не тикет


Und wie kann der HFT-Roboter getestet werden, wenn wir jedes Mal durch HistorySelect in die langsame Historie klettern müssen, um den Provisionsbetrag der aktuellen Position zu erhalten, und auf keinen Fall durch HistorySelectByPosition? Der Slippage der Pending Order wird zum Performance-Müll!

 

ACCOUNT_PROFIT im Testgerät zeigt Unsinn.

Führen Sie den Expert Advisor aus, der die Position sofort öffnet und schließt.

#include <MT4Orders.mqh>

#define  PRINT(A) Print(#A + " = " + (string)(A));

void OnTick()
{  
  static bool FirstRun = true;

  if (FirstRun && OrderSelect(OrderSend(_Symbol, OP_BUY, 1, 0, 0, 0, 0), SELECT_BY_TICKET))
  {
    PRINT(AccountInfoDouble(ACCOUNT_PROFIT))
    
    if (OrderClose(OrderTicket(), OrderLots(), 0, 0) && OrderSelect(OrdersHistoryTotal() - 1, SELECT_BY_POS, MODE_HISTORY))
      OrderPrint();
    
    FirstRun = false;          
  }
}

Das Ergebnis ist

2017.04.19 23:24:50.317 RTS-6.17,M1 (MetaQuotes-Demo): generating based on real ticks
2017.04.19 23:24:50.317 RTS-6.17,M1: testing of Experts\fxsaber\Test2.ex5 from 2017.04.06 00:00 to 2017.04.08 00:00 started
2017.04.19 23:24:50.419 RTS-6.17 : real ticks begin from 2017.04.06 00:00:00
2017.04.19 23:24:50.419 2017.04.06 09:45:01   deal #2  buy 1.00 RTS-6.17 at 114250 done (based on order #2)
2017.04.19 23:24:50.419 2017.04.06 09:45:01   deal performed [#2  buy 1.00 RTS-6.17 at 114250]
2017.04.19 23:24:50.419 2017.04.06 09:45:01   order performed buy 1.00 at 114250 [#2  buy 1.00 RTS-6.17 at 114250]
2017.04.19 23:24:50.421 2017.04.06 09:45:01   AccountInfoDouble(ACCOUNT_PROFIT) = 0.0
2017.04.19 23:24:50.421 2017.04.06 09:45:01   exchange sell 1.00 RTS-6.17 at 114200, close #2 (114200 / 114250)
2017.04.19 23:24:50.421 2017.04.06 09:45:01   deal #3  sell 1.00 RTS-6.17 at 114200 done (based on order #3)
2017.04.19 23:24:50.421 2017.04.06 09:45:01   deal performed [#3  sell 1.00 RTS-6.17 at 114200]
2017.04.19 23:24:50.421 2017.04.06 09:45:01   order performed sell 1.00 at 114200 [#3  sell 1.00 RTS-6.17 at 114200]
2017.04.19 23:24:50.421 2017.04.06 09:45:01   #3 2017.04.06 09:45:01 buy 1.00 RTS-6.17 114250 0 0 2017.04.06 09:45:01 114200 0.00 0.00 -56.44 0
2017.04.19 23:24:50.629 RTS-6.17,M1: 582089 ticks, 1573 bars generated. Environment synchronized in 0:00:00.063. Test passed in 0:00:00.421 (including ticks preprocessing 0:00:00.078).

ACCOUNT_PROFIT zeigt Null an, aber in Wirklichkeit sind es -56,44. Folglich werden Eigenkapital, Drawdown usw. falsch geschätzt.

PositionGetDouble(POSITION_PROFIT) - dasselbe.

 
fxsaber:

Und wie kann ein HFT-Roboter getestet werden, wenn man, um die Kommissionsgröße der aktuellen Position zu erfahren, jedes Mal über HistorySelect und nicht über HistorySelectByPosition in die Historie einsteigen muss? Die Slippage einer schwebenden Order zu sehen, wird zum Performance-Müll!

Arbeitet HistorySelect mit einer binären Suche im gewünschten Zeitintervall oder nicht? D.h. O(N) oder O(log(N))?
 
fxsaber:
Arbeitet HistorySelect mit einer binären Suche im gewünschten Zeitintervall oder nicht? D.h. O(N) oder O(log(N))?
Nein. Die binäre Suche ist in diesem Fall nicht anwendbar.
 
Slawa:
Nein. Die binäre Suche ist in diesem Fall nicht anwendbar.
Intern sind also beide Geschichten (Aufträge und Abschlüsse) nach Zeit sortiert. Wir sprechen hier von HistorySelect und nicht von HistorySelectByPosition, das überhaupt nicht optimiert ist.
 
fxsaber:
Intern sind also beide Geschichten (Aufträge und Abschlüsse) nach Zeit sortiert.

Tut mir leid, ich habe mich ein wenig aufgeregt.

Ja, sie sind nach Zeit sortiert. Der erste Datensatz wird mit einer binären Suche durchsucht.

1...185418551856185718581859186018611862186318641865186618671868...3184
Neuer Kommentar