Erros típicos e como lidar com eles quando se lida com o ambiente comercial - página 7
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
Receio que isso seja lógica tortuosa. Mas eu poderia estar errado, é claro. Seria interessante ouvir a lógica.
Arbitragem com mais de 3 pés
Arbitragem de 3+ pés
Diferentes lógicas podem ser usadas para este TS. Normalmente é o envio assíncrono de três pedidos. Mas, de fato, existem variantes em que um OrderSend sincronizado é enviado primeiro ao símbolo com maior probabilidade de ser forte. E se a OrderSend termina em uma posição aberta - as duas ordens OrderSendAsync menos prováveis são enviadas.
Nesta situação, pode parecer que a primeira "posição" - a ordem do mercado - precisa de um mecanismo para determinar se a primeira "posição" está incompleta. Mas o primeiro OrderSend passa por uma ordem limite ao preço atual ou um pouco pior. Portanto, não é considerada uma "posição". As outras duas são ordens de mercado, na maioria das vezes. E contá-las como "posições" permite evitar situações de reabertura de posições. Neste caso, esta contabilidade não tem nenhum efeito negativo.
Em resumo, como eu entendo - não haverá solução. Nem mesmo uma solução, mas um princípio de trabalho logicamente correto com o número de pedidos e posições.
Estou falando da função utilizada para qualquer estratégia, outros dizem - para cada estratégia - uma muleta diferente.
Este exemplo acabou sendo muito mais legal. O TP, que foi colocado pelo próprio corretor, foi redirecionado! E quase imediatamente (eu estava esperando por 115 ms - aparentemente foi um bug no MT5) após o recadastramento, o corretor colocou o próximo TP, que foi executado. Os comentários aos pedidos não apareceram na captura de tela. A cor verde éORDER_REASON_TP. Assim, a ordem de rejeição tem mesmo ORDER_POSITION_ID.
Esta não é uma ordem de rejeição, mas uma ordem normalmente preenchida que foi executada. Quando é executado, a identificação da posição é obtida.
Além disso, temos duas ordens, uma das quais não é executada. Agora a pergunta é: quantas posições (se essas ordens não fossem ordens de parada, mas ordens de posição), então - quantas posições sua abordagem retornaria para você? A resposta é: mais uma, o que é falso. Por que você faria isso então?
Esta não é mais uma ordem de rejeição, mas uma ordem normalmente preenchida - executada. Quando executado, é quando a identificação da posição é recebida.
Você tem a idéia errada.
Mais uma coisa: existem duas ordens, uma das quais não foi executada. Agora a pergunta é: quantas posições (se essas ordens não fossem ordens de parada, mas ordens de posição), então quantas posições sua abordagem retornaria para você? A resposta é: mais uma, o que é falso. Por que você faria isso então?
Vamos fazer isso novamente. Suponha que houvesse duas posições em aberto. E vamos definir a futura ordem de mercado deste tipo. A função retorna 2+1=3. O TS considera que há três posições e tudo está bem. Em 16 ms vem a camisa de força. O TS verifica quantas posições - 2+0=2. E precisa de três! - envia outra ordem de mercado. Depois novamente 2+1=3. E a ordem é executada, obtendo 3+0=3.
Em geral, como eu o entendo - não haverá solução. Nem mesmo uma solução, mas um princípio de trabalho logicamente correto com o número de pedidos e posições.
Estou falando da função utilizada para qualquer estratégia, outros dizem - para cada estratégia - uma muleta diferente.
Eu não mudei de idéia. A função permanece universal para 99,9% dos EAs e plataformas comerciais.
Você tem a idéia errada.
Vamos rever isso novamente. Suponha que houvesse duas posições em aberto. E nós colocamos este tipo de ordem de mercado futuro. A função retorna 2+1=3. O TS olha para três posições e tudo está OK. Em 16 ms vem a camisa de força. O TS verifica quantas posições - 2+0=2. E precisa de três! - envia outra ordem de mercado. Depois novamente 2+1=3. E a ordem é executada, obtendo 3+0=3.
#896615 - rejeitar, e NÃO tem uma posição de identificação.
Vamos colocar isto de outra forma. Suponha que houvesse duas posições em aberto. Recebemos um sinal para abrir uma terceira posição, enviar-nos um pedido comercial e obter esta ordem inversa de mercado. Se tivermos três posições, nossa EA passará a enviar outros pedidos comerciais usando um símbolo diferente. A função retorna 2+1=3. O TS olha para três posições e começa a calcular volumes, toma/para mais três posições - por outro símbolo, envia ordens de operação para abrir por outro símbolo. Depois de 16 ms chega a rebeldia de um símbolo do outro. TS olha quantas posições - 2(corrente)+3(2 posições e um mercado de outro símbolo)=5. E deveriam ser seis! - Envia outra ordem de mercado para o símbolo atual a um preço completamente diferente e calcula o volume e as decolagens/paradas de novas posições para o terceiro símbolo. Então a mesma confusão acontece novamente.
E depois estamos coçando a cabeça - por que ele ficou louco?
Ou você acha que precisa criar funções para apenas uma - sua - estratégia e lógica de construção de TS? Você está errado.
Eu não mudei de idéia. A função permanece universal para 99,9% dos EAs e plataformas comerciais.
Não. Apenas para uma lógica comportamental.
E há milhares deles.
Eu não mudei de idéia. A função permanece universal para 99,9% dos EAs e plataformas comerciais.
A função deve retornar o que lhe é pedido. Clara e incondicionalmente, e não para que o usuário decida o que precisa mais tarde.
A lógica que eu sugiro deveria ser assim
... Ou deveria ser assim:
E você sugere:
#896615 é rejeitado e NÃO tem uma posição de identificação.
Leia o número na terceira caixa vermelha esquerda na captura de tela acima.
Vamos colocar isto de outra forma. Suponha que houvesse duas posições em aberto. Obtemos um sinal para abrir uma terceira posição, enviar um pedido comercial e obter esta ordem de mercado redirecionada. Se tivermos três posições, nossa EA passará a enviar outros pedidos comerciais usando um símbolo diferente. A função retorna 2+1=3. O TS olha para três posições e começa a calcular volumes, toma/para mais três posições - por outro símbolo, envia ordens de operação para abrir por outro símbolo. Depois de 16 ms chega a rebeldia de um símbolo do outro. TS olha quantas posições - 2(corrente)+3(2 posições e um mercado de outro símbolo)=5. E deveriam ser seis! - envia outra ordem de mercado para o símbolo atual a um preço completamente diferente e calcula o volume e as decolagens/paradas de novas posições para o terceiro símbolo. Então a mesma confusão acontece novamente.
E depois coçamos a cabeça perguntando porque ele ficou louco.
Se você não escrever e não inventar a lógica comercial dobrada, você não apenas arranhará sua própria reputação. Entendo que entre os TK tortuosos, que provavelmente inundaram os freelancers, isto não é incomum. E porque o dinheiro não cheira mal, alguém os leva pelo princípio, se eles pedem merda, o fazem e esquecem. Nada nem mesmo perto disso jamais foi escrito em um pesadelo. Mas tenho certeza de que os freelancers sabem muito melhor do que eu sobre os graus de fezes entre TK. Portanto, sim, para TCs inadequados pode ser muito útil a opção proposta por @Combinator- fazer pés fora de TC, assim que encontrar uma ordem de mercado com identificação zero.
Ou você acha que temos que criar funções para apenas uma - sua - estratégia e lógica de construção do TS? Você está errado.
Acho que precisamos pensar, no mínimo. E não criar um ambiente adequado para a criação de abomináveis TCs. Infelizmente, não sou capaz de formular um critério para definir um fundo entre os TCs. Para não prejudicar ninguém, vou reverter a visão do mundo - eu mesmo no fundo, e o conhecido TK flutuará sobre as leis da física.
A receita, como se costuma dizer, é universal: