Erros, bugs, perguntas - página 1861

Novo comentário
 

outra questão - é normal que não haja bandeiras? build 1585

Alpari


fxopen



FxOpenAlpariMQ
COPY_TICKS_INFO
Licitações e/ou Pedidos		930168391679292
COPY_TICKS_TRADE
Último e Volume		2710610102924
COPY_TICKS_ALL
todas as carraças		364077426568182216

se em todo o ladoCOPY_TICKS_ALL =COPY_TICKS_INFO +COPY_TICKS_TRADE

então o que é que se iguala na Alpari?

 
kaus_bonus:

Alpari

fxopen

Eles não têm barbatanas.
 
fxsaber:
Não têm bandeiras.


é claro, mas então o que é acrescentado para obterCOPY_TICKS_ALL?

porque eles têmCOPY_TICKS_TRADE=0

e as carraças na história com as bandeiras em falta são as desconhecidasCOPY_TICKS_TRADE ?

 
kaus_bonus:


é claro, mas então o que é acrescentado para obterCOPY_TICKS_ALL?

porque eles têmCOPY_TICKS_TRADE=0

e as carraças da história com bandeiras em falta são desconhecidasCOPY_TICKS_TRADE ?

Penso que são as mãos tortas dos corretores.
 

HistoryDealGet* e HistoryOrderGet*-funções são escritas de forma muito estranha, em termos de desempenho.

Quando eu faço HistorySelect, por exemplo, para 100K registos individuais. A função HistoryDealGet-function requer como primeiro argumento não o número de registos na tabela de história, e um bilhete. E a mesa é ordenada por tempo, e não por bilhete. Portanto, a primeira coisa que a função HistoryDealGet faz, cada vez que executa, é correr através da mesa e procurar um bilhete correspondente.


Porquê um tal desperdício de recursos! Acontece que o primeiro bilhete e o mais recente serão executados a velocidades diferentes. E para obter todas as características do último negócio, o HistoryDealGet-functions percorre sempre toda a tabela.


Porque não torná-lo normal?

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


E como podemos testar o HFT-robot, se para obter o montante da comissão da posição actual, precisamos de entrar na história lenta através de HistorySelect de cada vez, e em nenhum caso através de HistorySelectByPosition? O escorregamento da ordem pendente transforma-se num lixo de desempenho!

 

O ACCOUNT_PROFIT no testador mostra disparates.

Agora gerimos um Conselheiro Especialista que abre e fecha a posição imediatamente

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

O resultado é

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, mas na realidade é -56,44. Como consequência, a equidade, drawdown, etc. são estimados incorrectamente.

PositionGetDouble(POSITION_PROFIT) - a mesma coisa.

 
fxsaber:

E como pode um HFT-robot ser testado, se para saber o tamanho da comissão da posição actual, precisa de entrar na história através de HistorySelect e em nenhum caso através de HistorySelectByPosition? Para ver o deslize de uma ordem pendente transformar-se num lixo de desempenho!

O HistorySelect funciona ou não através de uma pesquisa binária do intervalo de tempo solicitado? Isto é, O(N) ou O(log(N))?
 
fxsaber:
O HistorySelect funciona ou não através de uma pesquisa binária do intervalo de tempo solicitado? Isto é, O(N) ou O(log(N))?
Não. A pesquisa binária não é aplicável neste caso
 
Slawa:
Não. A pesquisa binária não é aplicável neste caso
Assim, internamente ambas as histórias (Ordens e Acordos) são ordenadas por tempo. Estamos a falar de HistorySelect, e não de HistorySelectByPosition, que não está de modo algum optimizada.
 
fxsaber:
Assim, internamente ambas as histórias (Ordens e Acordos) são ordenadas por tempo.

Desculpe, fiquei um pouco excitado.

Sim, eles são ordenados por tempo. O registo inicial é pesquisado com uma pesquisa binária.

1...185418551856185718581859186018611862186318641865186618671868...3184
Novo comentário
Razão: