Erros, bugs, perguntas - página 1861
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
outra questão - é normal que não haja bandeiras? build 1585
Alpari
fxopen
Licitações e/ou Pedidos
Último e Volume
todas as carraças
se em todo o ladoCOPY_TICKS_ALL =COPY_TICKS_INFO +COPY_TICKS_TRADE
então o que é que se iguala na Alpari?
Alpari
fxopen
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 ?
é 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 ?
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?
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
O resultado é
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.
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))?
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.
Desculpe, fiquei um pouco excitado.
Sim, eles são ordenados por tempo. O registo inicial é pesquisado com uma pesquisa binária.