ForumSezioni

Errori, bug, domande - pagina 1861

Nuovo commento

un'altra domanda - è normale che non ci siano bandiere? build 1585

Alpari


fxopen



FxOpenAlpariMQ
COPY_TICKS_INFO
Bid e/o Ask		930168391679292
COPY_TICKS_TRADE
Last e Volume		2710610102924
COPY_TICKS_ALL
tutti i tick		364077426568182216

se ovunqueCOPY_TICKS_ALL =COPY_TICKS_INFO +COPY_TICKS_TRADE

allora che cosa equivale ad Alpari?

kaus_bonus:

Alpari

fxopen

Non hanno le pinne.
fxsaber:
Non hanno bandiere.


è chiaro, ma allora cosa si aggiunge per ottenereCOPY_TICKS_ALL?

perché hannoCOPY_TICKS_TRADE=0

e le zecche nella storia con le bandiere mancanti sono le sconosciuteCOPY_TICKS_TRADE ?

kaus_bonus:


è chiaro, ma allora cosa si aggiunge per ottenereCOPY_TICKS_ALL?

perché hannoCOPY_TICKS_TRADE=0

e le zecche nella storia con le bandiere mancanti sono sconosciuteCOPY_TICKS_TRADE ?

Penso che siano le mani storte dei broker.

Le funzioni HistoryDealGet* e HistoryOrderGet* sono scritte in modo molto strano, in termini di prestazioni.

Quando faccio HistorySelect, per esempio, per 100K record individuali. La funzione HistoryDealGet richiede come primo argomento non il numero di record nella tabella della storia, e un biglietto. E la tabella è ordinata per tempo, e non per biglietto. Quindi, la prima cosa che la funzione HistoryDealGet fa, ogni volta che viene eseguita, è di scorrere la tabella e cercare un biglietto corrispondente.


Perché un tale spreco di risorse! Si scopre che il primissimo biglietto e quello più recente saranno eseguiti a velocità diverse. E per ottenere tutte le caratteristiche dell'ultima transazione, HistoryDealGet-functions percorrerà ogni volta l'intera tabella.


Perché non renderlo normale?

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


E come possiamo testare l'HFT-robot, se per ottenere l'importo della commissione della posizione corrente, abbiamo bisogno di entrare nella storia lenta attraverso HistorySelect ogni volta, e in nessun caso attraverso HistorySelectByPosition? Lo slippage dell'ordine pendente si trasforma in un cestino di prestazioni!

ACCOUNT_PROFIT nel tester mostra un'assurdità.

Eseguire l'Expert Advisor che apre e chiude la posizione immediatamente

#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;          
  }
}

Il risultato è

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 mostra zero, ma in realtà è -56,44. Di conseguenza, il capitale, il drawdown, ecc. sono stimati in modo errato.

PositionGetDouble(POSITION_PROFIT) - stessa cosa.

fxsaber:

E come può essere testato un HFT-robot, se per conoscere la dimensione della commissione della posizione corrente, è necessario entrare nella storia attraverso HistorySelect e non attraverso HistorySelectByPosition ogni volta? Vedere lo slippage di un ordine pendente si trasforma in un cestino di performance!

HistorySelect funziona attraverso una ricerca binaria dell'intervallo di tempo richiesto o no? Cioè O(N) o O(log(N))?
fxsaber:
HistorySelect funziona attraverso una ricerca binaria dell'intervallo di tempo richiesto o no? Cioè O(N) o O(log(N))?
No. La ricerca binaria non è applicabile in questo caso
Slawa:
No. La ricerca binaria non è applicabile in questo caso
Così internamente entrambe le storie (Ordini e Contratti) sono ordinate per tempo. Stiamo parlando di HistorySelect, e non di HistorySelectByPosition, che non è affatto ottimizzato.
fxsaber:
Così internamente entrambe le storie (Ordini e Contratti) sono ordinate per tempo.

Mi dispiace, mi sono un po' eccitato.

Sì, sono ordinati per tempo. Il record iniziale viene cercato con una ricerca binaria.

1...185418551856185718581859186018611862186318641865186618671868...3184
Nuovo commento