História do Tick - página 24
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
A julgar pelas consultas do indicador de carrapato, os dados do campo time_msk são um múltiplo de 1000. ou seja, não estamos falando de milissegundos, a resolução é de 1 segundo.
Pergunta: qual foi então o objetivo de ampliar a estrutura do MqlTick?
Não é assim com você?
Tenho uma demonstração na Openbroker e uma conta real no mesmo lugar. No servidor Access real todos dão o mesmo resultado. bem na demonstração o mesmo. Vejamos Si-6.16, RTS-6.16, SBRF-6.16. Todas as mudanças são múltiplos de 1000.
Não é assim?
Neste momento, a consulta SymbolInfoTick retorna zeros na estrutura MqlTick em vez de milissegundos reais (um múltiplo de 1000)
Por favor, aguarde a próxima construção.
PS a pedido CopyTicks milissegundos são dados como está
Fiz o download deste indicador a partir deste tópico para testá-lo. Recebe os últimos 30 ticks exatamente através de CopyTicks. Como opção, talvez eu devesse tentar em um servidor diferente (não um corretor aberto).
>> "são dados zeros em vez de milissegundos reais".
Não são dados zeros, mas sempre os mesmos números com um múltiplo de 1000. (...2064, ...2064, ...3064, ..., ..., ..4064 )
Fiz o download deste indicador a partir deste tópico para testá-lo. Recebe os últimos 30 ticks exatamente através de CopyTicks. Alternativamente, talvez eu devesse tentar em um servidor diferente (não um corretor aberto).
>> "são dados zeros em vez de milissegundos reais".
Não são dados zeros, mas sempre os mesmos números com um múltiplo de 1000. (...2064, ...2064, ...3064, ..., ..., ..4064 )
Os zeros são passados pela função SymbolInfoTick.
Em CopyTicks são dados milissegundos reais. Se estes são 2064, 3064, 4064, isso significa que foi assim. Por que foi assim, não sei.
Eu olhei através de seu código. Qual é o especificador de saída %-4d? time_msc é longo, então apenas d não funciona. Deve ser %I64d.
Os zeros são dados pela função SymbolInfoTick.
Em CopyTicks são dados milissegundos reais. Se é 2064, 3064, 4064, isso significa que foi assim. Por que foi assim, não sei.
Eu olhei através de seu código. Qual é o especificador de saída %-4d? time_msc é longo, então apenas d não funciona. Deve ser %I64d.
Sim, desculpe. O código não é meu. O autor do código realmente tem um deslize em StringFormat. Imprimi em cada iteração do loop através de Print (tick.time_msc) . O resultado são todos zeros no final e ainda não recebemos milissegundos. O pedido doCopyTicks persiste.
Os zeros são dados pela função SymbolInfoTick.
Em CopyTicks são dados milissegundos reais. Se é 2064, 3064, 4064, assim foi. Por que foi assim, não sei.
Veja o seu código. Qual é o especificador de saída %-4d? time_msc - é longo, é por isso que simplesmente d não funciona. Deve ser %I64d.
Indicador alterado do primeiro post - não brinque com StringFormat, deveria ser assim agora:
Sim, desculpe. O código não é meu. O autor realmente tem um bug em StringFormat. Imprimir (tick.time_msc) em cada iteração do laço. O resultado são todos zeros no final e ainda não recebemos milissegundos. O pedidoCopyTicks vai o tempo todo.
Aqui está seu indicador sobre os dados da MetaQuotes Demo
Pergunte a seu corretor sobre ausência de milissegundos em carrapatos
Aqui está seu indicador sobre os dados da MetaQuotes Demo
Pergunte a seu corretor sobre a falta de milissegundos em carrapatos
ps meu cliente constrói 1340
juriy5555 :
Пока не знаю, что и у кому конкретно писать, я в этом несколько месяцев. Буду надеяться, что ОпенБрокер всё таки обновит сервер.
ps мой билд клиента 1340
Também tenho uma dúvida, embora um plano um pouco diferente, e também gostaria de saber se as informações transmitidas pelos carrapatos estão corretas.
Uma pergunta sobre volumes reais.
Se você solicitar informações sobre ticks do indicador, o volume real vai para lá no array volume[]. E, em teoria, se você obtiver informações de ticks, o volume acumulado por vela deve corresponder ao valor da matriz volume[].
Aqui está um exemplo de código de teste:
Não vamos nos apegar aos sinalizadores por enquanto e assumir que cada tick recebido altera o volume total de sVol (embora, até onde eu saiba, esse não seja o caso).
Estamos aguardando a formação de uma nova vela e observe as entradas no diário. Abertura de corretora, conta real, build 1340, RTS-6.16:
E assim sucessivamente, o volume real do indicador será muito maior que o acumulado. Isso levanta algumas questões para os desenvolvedores:
1. O volume obtido do array volume[] da função OnCalculate() deve ser igual ao volume acumulado obtido dos ticks? Minha opinião, é claro, deveria, caso contrário, por que indicá-la em carrapatos?
2. É correto utilizar a função OnCalculate() para acumular o volume, ou é melhor obter o volume através do OnBookEvent()? A ajuda diz:
O evento Calcular é gerado apenas para indicadores imediatamente após o envio do evento Init e após qualquer alteração nos dados de preço. Manipulado pela função OnCalculate.
então, em teoria, está correto, mas eu gostaria de ouvir um comentário sobre isso.
3. Os resultados do teste são mostrados SEM análise de sinalizadores. Se analisarmos os sinalizadores, pelo que entendi, você precisa obter volumes de ticks com sinalizadores 24 (mudança simultânea no último e no volume):
Mas neste caso, o volume acumulado será ainda menor. Gostaria de ouvir os comentários dos desenvolvedores sobre como analisar corretamente os ticks agora (já que todos os campos são gravados) e os sinalizadores estão implementados corretamente? A questão sobre a correção da implementação surgiu porque não notei carrapatos com sinalizadores:
O arquivo do indicador também está no aplicativo.