É possível implementar uma contabilidade FELICITÁVEL da estrutura de posição agregada na MT5? - página 18
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
Suas afirmações ousadas em várias ocasiões (minhas qualificações, a situação no MC, etc.) de certa forma reduzem o interesse em sua opinião, não acha?)) De alguma forma não faz sentido responder a você - por que responder às declarações de uma pessoa claramente inadequada? )))
Para começar, pare de confundir alucinações com a realidade - vamos conversar.
É isso aí, eu me acalmei.
Sobre o que devemos falar?
Já tenho minha caneta e meu notebook prontos.
>> Estou lhe ouvindo, senhor.
Apenas esclarecido. Como o nível SL não é garantido de forma alguma e é executado nos mercados somente por solicitação do Mercado, então a obrigação de não atingir o nível TP não é necessária. Pouco antes de executar SL no mercado, o Execution-server (Dukascopy) apaga o nível TP (mesmo que esteja no pick). Este é o ponto que, infelizmente, não pode ser HOPEFULLY implementado pelo trader no MT5, mesmo que ele tenha uma conexão perfeita com o servidor de negociação. E é, de fato, REALMENTE IMPOSSÍVEL no MT5.
Eis como vemos a solução para este problema:
um link (FILL->KILL) é introduzido no nível de servidor de negociação MT5 entre ordens Limit e Stop, o que dá o seguinte
- Antes de fazer uma ordem de parada de atendimento ao mercado, o servidor Execution apaga a ordem Limit associada a ela.
- Quando uma ordem de limite é acionada, o servidor Execution apaga a ordem de parada relacionada a ela.
Todos os problemas discutidos são resolvidos de forma bastante simples - através da introdução de pedidos condicionais no servidor. Isto, a propósito, é feito em muitos corretores que trabalham de acordo com o esquema clássico de intercâmbio. Para este fim, ao estabelecer um pedido, devemos acrescentar a possibilidade de estabelecer um pedido vinculado a ser cancelado e inserido. A lógica é elementar: se a ordem A é executada, então as ordens B e C são colocadas. O mesmo se aplica ao cancelamento: se a ordem A é executada, B e C são cancelados. Ou vice versa: a ordem B é cancelada se a ordem A tiver chegado à execução. E então o problema de calcular a posição agregada é resolvido elementar, assim como o problema de ajuste e cancelamento de TP e SL. Além disso, dá muitas possibilidades adicionais.
Z.U. Depois de escrever, vi que a getch já havia mencionado isso em um post antes. Somente não é necessário conectar apenas limitar e interromper as ordens. Se alguma puder ser interligada, há muito mais possibilidades.
Para: getch
Решение данной проблемы видится так:
вводится связь (FILL->KILL) на уровне торгового сервера MT5 между Limit-ордерами и Stop-ордерами, которая дает следующее:
- перед тем, как сделать маркет-сиполнение Stop-ордера, удаляется Execution-сервером связанный с ним Limit-ордер.
- после срабатывания Limit-ордера, удаляется Execution-сервером связанный с ним Stop-ордер.
Isto é difícil de fazer porque os pedidos têm bilhetes diferentes.
Você tem que entrar em mais um campo no servidor e no terminal,
e a MQ não irá para um movimento tão fora do padrão.
TP e SL existem. Então e se for uma posição agregada.
Como disse a Integer - as paradas são um último recurso :-)
Para Avals:
Este tópico não é sobre como, pode ser feito de forma alguma.
Isso pode ser feito.
Este tópico trata da confiabilidade da execução de pedidos com múltiplos EAs e uma posição agregada.
Esta não é a opção mais confiável.
Para: getch
Isto é difícil de fazer porque os pedidos têm bilhetes diferentes.
Você precisa entrar em mais um campo no servidor e no terminal,
e a MQ não irá para um movimento tão fora do padrão.
TP e SL existem. Então e se for uma posição agregada.
Como disse a Integer - as paradas são um último recurso :-)
MQ e SL são os mesmos da getch))))) e é 100% confiável e padrão implementado na maioria dos softwares de corretagem
Todos os problemas discutidos são resolvidos de forma bastante simples - através da introdução de pedidos condicionais no servidor. Isto, a propósito, é feito em muitos corretores que trabalham de acordo com o esquema clássico de intercâmbio. Para este fim, ao estabelecer um pedido, devemos acrescentar a possibilidade de estabelecer um pedido vinculado a ser cancelado e inserido. A lógica é elementar: se a ordem A é executada, então as ordens B e C são colocadas. O mesmo se aplica ao cancelamento: se a ordem A é executada, B e C são cancelados. Ou vice versa: a ordem B é cancelada se a ordem A tiver chegado à execução. E então o problema de calcular a posição agregada é resolvido elementar, assim como o problema de ajuste e cancelamento de TP e SL. Além disso, dá muitas possibilidades adicionais.
Z.U. Depois de escrever, vi que a getch já havia mencionado isso em um post antes. Só que não precisamos conectar apenas limitar e interromper as ordens. Se você puder ligar alguma, as possibilidades são muito maiores.
Erro meu, não o entendi. É uma boa idéia. Algum tipo de mini roteiros.
Mas o problema é que esta é uma carga ainda maior no servidor do que o armazenamento de itens não-cumulativos.
Erro meu, eu não resolvi o problema. Essa é uma boa idéia. Uma espécie de mini roteiros.
Mas o problema é que é uma carga ainda maior no servidor do que o armazenamento de itens não-cumulativos.
Portanto, o usuário ainda entrará com estes pedidos. Na verdade, tudo é elementar e não consome nenhum recurso. É uma parte necessária de qualquer plataforma. Por exemplo, QUIKa tem http://www.quik.ru/about/features/conditional-orders/.
A Alpha-Direct o tem http://www.alfadirect.ru/help3_3/index.htm e outras plataformas de comércio burguesas o têm. Não me lembro de nenhum terminal que não o tenha.
Eu escrevi o mesmo que getch)))) e é uma etapa 100% confiável e padrão implementada na maioria dos softwares de corretagem
Mais possibilidades são dadas por ordens OCO comuns (os mini-escritos mais primitivos no servidor comercial). A bandeira FILL->KILL no MT5 parece ser suficiente. Algumas empresas (a la StrategyRunner) escolheram a forma de armazenar scripts e até mesmo Expert Advisors em seus servidores. Este caminho tem suas vantagens (discutíveis) e desvantagens (discutíveis). A MetaQuotes foi por outro caminho.
Mais oportunidades são oferecidas por ordens OCO comuns (mini-escritos primitivos no servidor comercial). A bandeira FILL->KILL no MT5 parece ser suficiente. Algumas empresas (a la StrategyRunner) escolheram a forma de armazenar scripts e até mesmo Expert Advisors em seus servidores. Este caminho tem suas vantagens (discutíveis) e desvantagens (discutíveis). A MetaQuotes foi por outro caminho.
Ainda não está muito claro qual o caminho que escolheram))))