Longo Spread entre ask/bid e last price no MqlTick e Times and Trades
Boa noite Daniel,
você usou o copyticks() para fazer o CSV? Senão, então eu acho mais apropriado você fazer seu estudo exportando os Ticks da base de produção usando o próprio MT5. Veja o print abaixo como fazer.
Servidor XPPROD
Olá!
Este é meu primeiro tópico no fórum, mas já venho programando no MQL5 há alguns meses.
Eu observei, em momentos de alta volatilidade nos contratos futuros de índice bovespa, longos spreads entre os preços ask/bid dos mini contratos em relação ao cheio. Porém, não consegui acreditar que pudesse haver um spread entre os 2 de muitas vezes mais do que 50 pontos. Sendo assim decidi exportar em CSV o times and trades referente à estes momentos de spread, com a finalidade de observar se esses negócios foram realmente realizados ou seria uma informação errônea da plataforma.
Com isso reparei que os preços de ask and bid, nestes momentos de alta volatilidade, diferem na mesma métrica dos preços que estão realmente sendo negociados no mercado, o preço last.
Para ilustrar, exportei em CSV o Times and Trades do book e montei um EA que avisasse quando o spread entre o bid do mini e o ask do cheio fosse maior que 50 pontos, além de registrar o volume do book dos preços mais próximos.
Infelizmente, não peguei a situação ocorrendo no times and trades e no EA acontecendo no mesmo momento (pelo menos não encontrei a foto aqui), mas em momentos diferentes, ocorrendo a mesma situação.
No times and Trades:
Reparem que os preços de bid e ask se mantem os mesmos , estando 50 pontos longe do preço do último negócio, o preço last.
No EA eu coloquei para gerar alertas quando ocorrese a situação bid / ask do cheio e mini diferirem de 50 pontos. E o resultado foi:
O que vocês acham que pode estar acontecendo??
Eu pensei que pudesse ser agressões que carregam e consomem todo o book na região e não fosse possível atualizar os preços de ask e bid à tempo, tendo em vista que, olhando o CSV, os preços variam no mesmo milisegundo.
Tendo em vista que sou novo no fórum, peço perdão por qualquer inconveniente.
Abraços!
O que está acontecendo nesse trecho do log é que alguém executou uma ordem de compra a mercado com um volume muito grande, que consumiu a liquidez de vários níveis da fila de ofertas de venda (ask) de uma vez só.
Repare que há duas longas sequências de ticks processados exatamente no mesmo horário (mesmo milésimo de segundo). Isso aí é uma única ordem a mercado de volume grande consumindo várias ordens pendentes de volume pequeno de uma só vez.
O que acontece aí é que o ask devia estar em 94410 quando a ordem de compra gigante foi executada e consumiu em 1 milésimo de segundo todas as ofertas de venda a 94410, 94415, 94420, ... até 94450.
Somente depois do processamento do último tick de compra a 94450 é que começaram a ser processados os ticks notificando alteração de bid/ask ... logo após esta sequência vc vai ver ticks de notificação de mudança de preços bid/ask subindo o preço ASK para 94415, 94420, ... até 94450.
Esta aparente defasagem que você vê é apenas porque os ticks que notificações de execução de negócio chegaram antes dos ticks de notificação de mudança de bid/ask, mas provavelmente todos terão chegados "no mesmo instante" (mesmo milésimo de segundo, ou poucos milésimos de segundo de diferença).
Se vc tentasse comprar a 94410 neste mesmo milésimo de segundo, vc não conseguiria, pois a ordem gigante estaria na frente da sua consumindo tudo ... se neste mesmo milésimo de segundo vc tivesse enviado uma limit order, ela ficaria pendente, não preenchida, em 94410 ...e se vc tivesse enviado uma ordem de compra a mercado, ela seria executada a 94450, com 40 pontos de slippage.
Bom dia a todos,
uma observação, na minha postagem eu assinalei com linha azul os preços de WINJ19 momento antes de iniciar as negociações no preço de 94450, e são: 94445/94450 veja estão bem diferentes do apontado no CSV. Acredito que existe algum erro na geração do arquivo, por isso eu coloquei na nota minha indagação se tinha usado o comando CopyTicks(...).
As anotações do Patinhas estão totalmente corretas e essa minha nota é apenas para constatar que os preços 94400/94410 no CSV estão incorretos. Em anexo o arquivo de ticks baixado de XP_DEMO com tempo de milisegundos.
O que está acontecendo nesse trecho do log é que alguém executou uma ordem de compra a mercado com um volume muito grande, que consumiu a liquidez de vários níveis da fila de ofertas de venda (ask) de uma vez só.
Repare que há duas longas sequências de ticks processados exatamente no mesmo horário (mesmo milésimo de segundo). Isso aí é uma única ordem a mercado de volume grande consumindo várias ordens pendentes de volume pequeno de uma só vez.
O que acontece aí é que o ask devia estar em 94410 quando a ordem de compra gigante foi executada e consumiu em 1 milésimo de segundo todas as ofertas de venda a 94410, 94415, 94420, ... até 94450.
Somente depois do processamento do último tick de compra a 94450 é que começaram a ser processados os ticks notificando alteração de bid/ask ... logo após esta sequência vc vai ver ticks de notificação de mudança de preços bid/ask subindo o preço ASK para 94415, 94420, ... até 94450.
Esta aparente defasagem que você vê é apenas porque os ticks que notificações de execução de negócio chegaram antes dos ticks de notificação de mudança de bid/ask, mas provavelmente todos terão chegados "no mesmo instante" (mesmo milésimo de segundo, ou poucos milésimos de segundo de diferença).
Se vc tentasse comprar a 94410 neste mesmo milésimo de segundo, vc não conseguiria, pois a ordem gigante estaria na frente da sua consumindo tudo ... se neste mesmo milésimo de segundo vc tivesse enviado uma limit order, ela ficaria pendente, não preenchida, em 94410 ...e se vc tivesse enviado uma ordem de compra a mercado, ela seria executada a 94450, com 40 pontos de slippage.
Isso é meio perigoso pros usuários não?? O fato de o preço real estar tão longe do bid e ask (que estão errados efetivamente, não?).
Acredito que possa induzir muitos usuários ao erro, caso estes não verifiquem a relação bid/ask/last, não?
Eu fui olhar no CSV e percebi que a situação só se estabilizou quase 4 segundos depois (uma eternidade para um robô).
O que acham dessa situação?? Há uma maneira de revertê-la? Obter só as informações de maneira "sincronizada" (last x bid x ask)?
Outra pergunta seria: como observar uma situação dessa ocorrendo? Como saber que alguém consumiu o book com uma grande ordem??
Ví que o book tem uma propriedade TYPE_SELL_MARKET (que eu não entendi muito bem, para ser sincero). Seria o caso de verificar se as últimas ordens foram do tipo???
Obrigado pelas respostas!! Grande abraço!
@DanielStreet
Boa noite Daniel,
você usou o copyticks() para fazer o CSV? Senão, então eu acho mais apropriado você fazer seu estudo exportando os Ticks da base de produção usando o próprio MT5. Veja o print abaixo como fazer.
Servidor XPPROD
Quanto ao EA, o que uso é SymbolInfoTick.
abraços!!
No caso não usei. Eu estava com o book do meta trader aberto e coloquei para ver os negócios (Times and Sales), e neste têm uma opção de exportar para csv.
Quanto ao EA, o que uso é SymbolInfoTick.
abraços!!
Agora não entendo mais nada, como é que pode?
A exportação de os ticks pela tela de "ATIVOS" mostra um preço e exportação de ticks pelo Time and Sales mostra outros preços!
Alguém responde?
Agora não entendo mais nada, como é que pode?
A exportação de os ticks pela tela de "ATIVOS" mostra um preço e exportação de ticks pelo Time and Sales mostra outros preços!
Alguém responde?
Como diria o ditado: "Eitaaaaa!"
Agora não entendo mais nada, como é que pode?
A exportação de os ticks pela tela de "ATIVOS" mostra um preço e exportação de ticks pelo Time and Sales mostra outros preços!
Alguém responde?
Agora não entendo mais nada, como é que pode?
A exportação de os ticks pela tela de "ATIVOS" mostra um preço e exportação de ticks pelo Time and Sales mostra outros preços!
Alguém responde?
eu não consegui ver muito bem este erro que você falou, porém, vou dar upload no arquivo inteiro aqui pro caso de você querer ver com mais clareza a situação.
PS: me avisem se foi o arquivo, pois estou tentando adicionar e aqui não aparece nenhum arquivo anexado
PS2: fiquei pensando, acho que coloquei o tópico no local errado, acho que seria mais algo "Geral" do que "robôs de negociação".
Se algum moderador concordar e puder mover...
Arquivo com formato .csv não é permitido e não dá nenhuma mensagem de erro. "Zipa" e anexa.
Arquivo com formato .csv não é permitido e não dá nenhuma mensagem de erro. "Zipa" e anexa.
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Você concorda com a política do site e com os termos de uso
Olá!
Este é meu primeiro tópico no fórum, mas já venho programando no MQL5 há alguns meses.
Eu observei, em momentos de alta volatilidade nos contratos futuros de índice bovespa, longos spreads entre os preços ask/bid dos mini contratos em relação ao cheio. Porém, não consegui acreditar que pudesse haver um spread entre os 2 de muitas vezes mais do que 50 pontos. Sendo assim decidi exportar em CSV o times and trades referente à estes momentos de spread, com a finalidade de observar se esses negócios foram realmente realizados ou seria uma informação errônea da plataforma.
Com isso reparei que os preços de ask and bid, nestes momentos de alta volatilidade, diferem na mesma métrica dos preços que estão realmente sendo negociados no mercado, o preço last.
Para ilustrar, exportei em CSV o Times and Trades do book e montei um EA que avisasse quando o spread entre o bid do mini e o ask do cheio fosse maior que 50 pontos, além de registrar o volume do book dos preços mais próximos.
Infelizmente, não peguei a situação ocorrendo no times and trades e no EA acontecendo no mesmo momento (pelo menos não encontrei a foto aqui), mas em momentos diferentes, ocorrendo a mesma situação.
No times and Trades:
Reparem que os preços de bid e ask se mantem os mesmos , estando 50 pontos longe do preço do último negócio, o preço last.
No EA eu coloquei para gerar alertas quando ocorrese a situação bid / ask do cheio e mini diferirem de 50 pontos. E o resultado foi:
O que vocês acham que pode estar acontecendo??
Eu pensei que pudesse ser agressões que carregam e consomem todo o book na região e não fosse possível atualizar os preços de ask e bid à tempo, tendo em vista que, olhando o CSV, os preços variam no mesmo milisegundo.
Tendo em vista que sou novo no fórum, peço perdão por qualquer inconveniente.
Abraços!