MqlTick.flags zerado - página 2
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
O autor desse tópico aí é um velho conhecido meu. Um dia ele perdeu a senha da conta e um feitiço o transformou em pato ;-)
pqp! :D
Flávio, na B3 muitos ticks vêm com os flags BUY e SELL acesos simultaneamente.
Acredito que sejam os chamados "negócios diretos": a corretora junta ofertas de compra e de venda de clientes seus e, em vez de enviar as ordens pro mercado, manda apenas a notificação de "negócio direto" para a B3 (isso é obrigatório por lei, pois não pode haver negócio fora do pregão).
Fiz uns estudos há tempos atrás e vi que no mini-índice essas situações de BUY e SELL acesos simultaneamente chegavam a mais de 1% do volume total dos negócios em alguns dias.
Nesse teu código aí em cima, os volumes dos ticks que vierem com BUY e SELL acesos simultaneamente não serão somados nem no bufferBuy nem no bufferSell, de modo que, no fim do dia, a soma bufferBuy + bufferSell vai ficar um pouquinho menor que o volume total de negócios. Não sei se isso é relevante para a sua estratégia, mas é bom vc estar ciente de que essa soma não vai bater e o motivo disso.
Na minha versão do teu código acima (eu também faço isso), no caso dos flags com BUY e SELL acesos ao mesmo tempo, eu somo metade do volume pra BUY e metade pra SELL. Desta forma a soma bate. Mas se vc for criar indicadores baseados na proporção entre agressão de compra e de venda, tipo BUY/(BUY+SELL) e SELL/(BUY+SELL), aí já fica meio discutível como deveriam ser contabilizados os ticks "biagressores". Descartá-los, como você faz, talvez não seja uma solução ruim. Eles são 1% ou menos do volume total, então talvez essa discussão seja preciosismo excessivo.
O pior é que já constatei que esses flags às vezes variam de corretora pra corretora (uma diz que é BUY e outra diz que é SELL, pro mesmo tick). São muito raros os ticks cujos flags BUY/SELL variam entre corretoras, mas no mini-dolar e no mini-indice todos os dias tem alguns.
Isso me faz me perguntar(*) se essa informação dos flags BUY e SELL (quem foi a parte agressora) vem mesmo da bolsa ou se é o MT5 que tenta inferir esses flags comparando LAST com BID e ASK. Neste último caso, se os ticks chegarem fora da ordem (lembrar que o protocolo TCP/IP usado na internet não garante que os pacotes cheguem na mesma ordem em que foram enviados), cada instância de MT5 pode fazer uma inferência diferente, o que explicaria a existência de algumas raras discrepâncias entre corretoras (se a informação viesse da bolsa, deveria ser rigorosamente a mesma em todas as corretoras, pois o TCP/IP garante a entrega de todos os pacotes a todos os destinos, embora não necessariamente na mesma ordem).
(*) lembrei do Led Zeppelin quando escrevi isso ... "hmmm, it makes me wonder..."
Obrigado pelas observações. Como sempre, vc já passou o perrengue primeiro! :D Obrigado por isso!
Deixo aqui meus achados pra galera não sofrer o mesmo que nós...
Lembrete: Só testei na Modal. Portanto cuidado e retestem em sua corretora.
Ainda prefiro usar o SymbolInfoTick() pela performance e evita de ter que gerar loops para reconferir ticks passados...
Como meu indicador pode ser "imperfeito" e meu período de monitoramento é extremamente curto (2 seg) estou ignorando os Diretos.
Na minha análise passada, pra um cara como eu que operava Tape Reading, eu via influência dos Diretos na hora do Cálculo do Ajuste, onde os big players "sacaneavam"/"sacaneiam" o preço...
De novo, galera, o código acima é por conta e risco seu, cabem a vocês testarem. Eu apenas testei ma B3/Dolar/Indice. Pra mim é suficiente...
Saludos!
;)
Isso me faz me perguntar(*) se essa informação dos flags BUY e SELL (quem foi a parte agressora) vem mesmo da bolsa ou se é o MT5 que tenta inferir esses flags comparando LAST com BID e ASK. Neste último caso, se os ticks chegarem fora da ordem (lembrar que o protocolo TCP/IP usado na internet não garante que os pacotes cheguem na mesma ordem em que foram enviados), cada instância de MT5 pode fazer uma inferência diferente, o que explicaria a existência de algumas raras discrepâncias entre corretoras (se a informação viesse da bolsa, deveria ser rigorosamente a mesma em todas as corretoras, pois o TCP/IP garante a entrega de todos os pacotes a todos os destinos, embora não necessariamente na mesma ordem).
(*) lembrei do Led Zeppelin quando escrevi isso ... "hmmm, it makes me wonder..."
Tenho também esta dúvida... uma vez tentei entender o PUMA, que usa throttling para o Book, não sei como a B3 envia o Market Data de Times & trades para as corretoras, e como elas gerenciam isso...
Como no meu caso o ótimo é inimigo do bom, e preciso de performance em menos de 2 segundos, relevei...
Mas fica o link para estudo...
http://www.b3.com.br/data/files/22/75/54/25/A7915610BE423F46AC094EA8/UMDFConflated_MarketDataSpecification2.0.10.pdf
http://www.b3.com.br/pt_br/solucoes/plataformas/puma-trading-system/para-desenvolvedores-e-vendors/umdf-puma-conflated/
Abraços!
;)
Ainda prefiro usar o SymbolInfoTick() pela performance e evita de ter que gerar loops para reconferir ticks passados...
Se você usar CopyTicks() com count=1, só vai vir o tick mais recente. Sem necessidade de loop. Não cheguei a comparar performance com SymbolInfoTick(), mas acredito que seja semelhante.
Se vc estiver interessado apenas nos valores mais recentes de bid, ask, last, SymbolInfoTick() é perfeita.
Se estiver interessado nos flags, melhor usar CopyTicks() com count=1, por causa do problema dos flags zerados que foi relatado nesta thread.
Mas se estiver somando os volumes negociados para calcular, tick a tick, indicadores baseados em fluxo, então não dá pra usar SymbolInfoTick() nem CopyTicks() com count=1, senão vc vai perder ticks entre uma leitura e outra e a soma ficará errada.
Pra calcular em tempo real fluxo e volume acumulado tick a tick, a minha primeira tentativa há tempos atrás foi usar CopyTicks() e fazer um loop pra trás até encontrar um tick que eu já tinha lido anteriormente, pra saber quais eram os novos e fazer a soma correta.
Mas aí surge um outro problema: é muito comum virem 2 ou mais ticks de buy ou sell exatamente iguais: mesmo time_msc (mesmo milésimo de segundo), mesmo bid, mesmo ask, mesmo last, mesmo volume e mesmos flags.
Basta, por exemplo, vir uma ordem de compra a mercado de volume grande e as N primeiras ordens de venda no book terem o mesmo volume. No dólar cheio isso é muito comum, pois a maior parte das ordens limitadas usam o lote mínimo, de modo que uma ordem a mercado de volume grande frequentemente "enxuga" várias ordens limitadas idênticas no mesmo milésimo de segundo. Isso gera N ticks exatamente iguais, cujos volumes têm que ser somados corretamente (sem repetir, nem faltar nenhum tick).
Nesse caso, como saber se você está lendo um tick que já foi lido (que não deve ser somado de novo) ou se é um novo tick igual ao lido anteriormente (que precisa ser somado) ?
Eu soluciono isso usando CopyTicksRange. Em cada leitura, desprezo os ticks recebidos no milésimo de segundo mais recente que aparecer no array retornado e, na leitura seguinte, configuro a faixa para começar exatamente a partir do milésimo de segundo que desprezei na leitura anterior. Dessa forma, todos os ticks são processados 1 e somente 1 vez (nenhum tick é processado mais de uma vez e nenhum tick deixa de ser processado), garantindo resultado correto nos cálculos.
Tenho também esta dúvida... uma vez tentei entender o PUMA, que usa throttling para o Book, não sei como a B3 envia o Market Data de Times & trades para as corretoras, e como elas gerenciam isso...
Como no meu caso o ótimo é inimigo do bom, e preciso de performance em menos de 2 segundos, relevei...
Mas fica o link para estudo...
http://www.b3.com.br/data/files/22/75/54/25/A7915610BE423F46AC094EA8/UMDFConflated_MarketDataSpecification2.0.10.pdf
http://www.b3.com.br/pt_br/solucoes/plataformas/puma-trading-system/para-desenvolvedores-e-vendors/umdf-puma-conflated/
Abraços!
;)
Preciosa essa informação!
Talvez isso explique as diferenças (geralmente da ordem de 1 a 2 ms) entre os ticks BUY/SELL e os ticks BID/ASK.
Quando tem uma ordem a mercado grande que varre vários níveis de preço de uma vez só, fica bem nítida essa diferença no log.
Pegando o mesmo evento em duas corretoras, já vi em uma corretora, por exemplo, virem todos os ticks de BUY primeiro, com preço last aumentando (3700.0, 3700.5, 3701.0, 3701.5 ...) e 1 ou 2 milissegundos depois vêm os ticks ASK (3700.5, 3701.0, 3701.5 ...) e na outra corretora estava o contrário: primeiro os ticks de ASK aumentando o preço e depois os ticks de SELL.
Se você usar CopyTicks() com count=1, só vai vir o tick mais recente. Sem necessidade de loop. Não cheguei a comparar performance com SymbolInfoTick(), mas acredito que seja semelhante.
Se vc estiver interessado apenas nos valores mais recentes de bid, ask, last, SymbolInfoTick() é perfeita.
Se estiver interessado nos flags, melhor usar CopyTicks() com count=1, por causa do problema dos flags zerados que foi relatado nesta thread.
Mas se estiver somando os volumes negociados para calcular, tick a tick, indicadores baseados em fluxo, então não dá pra usar SymbolInfoTick() nem CopyTicks() com count=1, senão vc vai perder ticks entre uma leitura e outra e a soma ficará errada.
Pra calcular em tempo real fluxo e volume acumulado tick a tick, a minha primeira tentativa há tempos atrás foi usar CopyTicks() e fazer um loop pra trás até encontrar um tick que eu já tinha lido anteriormente, pra saber quais eram os novos e fazer a soma correta.
Mas aí surge um outro problema: é muito comum virem 2 ou mais ticks de buy ou sell exatamente iguais: mesmo time_msc (mesmo milésimo de segundo), mesmo bid, mesmo ask, mesmo last, mesmo volume e mesmos flags.
Basta, por exemplo, vir uma ordem de compra a mercado de volume grande e as N primeiras ordens de venda no book terem o mesmo volume. No dólar cheio isso é muito comum, pois a maior parte das ordens limitadas usam o lote mínimo, de modo que uma ordem a mercado de volume grande frequentemente "enxuga" várias ordens limitadas idênticas no mesmo milésimo de segundo. Isso gera N ticks exatamente iguais, cujos volumes têm que ser somados corretamente (sem repetir, nem faltar nenhum tick).
Nesse caso, como saber se você está lendo um tick que já foi lido (que não deve ser somado de novo) ou se é um novo tick igual ao lido anteriormente (que precisa ser somado) ?
Eu soluciono isso usando CopyTicksRange. Em cada leitura, desprezo os ticks recebidos no milésimo de segundo mais recente que aparecer no array retornado e, na leitura seguinte, configuro a faixa para começar exatamente a partir do milésimo de segundo que desprezei na leitura anterior. Dessa forma, todos os ticks são processados 1 e somente 1 vez (nenhum tick é processado mais de uma vez e nenhum tick deixa de ser processado), garantindo resultado correto nos cálculos.
Obrigado pelas informações!
Acho que vou seguir com SymbolTickInfo() por agora... É um experimento e ele pode ser imperfeito... Eu só preciso de Compras e Vendas... E segundo a documentação do MQL5 os Flags que uso são os corretos mesmo... Acabei de checar...
Tentei analisar um trecho breve de logs dos ticks e passo a acreditar que, já que não encontrei nenhum padrão visível, os UNKNOWNS (os Flags Zerados) são os diretos...
;)
Muito interessante essa discussão!
Aproveito para compartilhar um artigo que corrobora com o que o Trader_Patinhas disse sobre o problema de virem dois ou mais ticks com mesmo timestamp.
https://www.mql5.com/pt/articles/3708
Muito interessante essa discussão!
Aproveito para compartilhar um artigo que corrobora com o que o Trader_Patinhas disse sobre o problema de virem dois ou mais ticks com mesmo timestamp.
https://www.mql5.com/pt/articles/3708
Não li o artigo.
O que eu consegui deduzir - posso estar errado - pelos logs que interpretei da B3/DOL, é quando uma Venda ou Compra esbarra em um lote iceberg, que sai naquele mesmo instante, afinal a ordem continua na frente da fila do book até ser toda consumida... Mas todos os ticks são válidos, não são repetidos, muito pelo contrário, tratava-se de uma ordem grande que consumiu várias "Boletas" de uma ordem iceberg.
Posso estar errado...
;)
Não li o artigo.
O que eu consegui deduzir - posso estar errado - pelos logs que interpretei da B3/DOL, é quando uma Venda ou Compra esbarra em um lote iceberg, que sai naquele mesmo instante, afinal a ordem continua na frente da fila do book até ser toda consumida... Mas todos os ticks são válidos, não são repetidos, muito pelo contrário, tratava-se de uma ordem grande que consumiu várias "Boletas" de uma ordem iceberg.
Posso estar errado...
;)
Flavio, boa tarde.
Acredito que não, pois tem casos de 4 ou 5 ticks com flag zerado com volume 1 em valor X, e depois outros com flag preenchida no mesmo valor. Se não me engano, estes icebergs tem um volume mínimo de 50 certo?
Obs.: Estou fazendo alguns testes com o CopyTicks, acredito que este resolva o meu problema, quando terminar posto aqui.
Obrigado.
Jhoni Carlos da Silva.
Posta sim! Vamos esclarecer esse assunto e deixar gravado aqui pra outros não passarem pelo que estamos passando hoje...
;)