Organizando o ciclo do pedido - página 4

Novo comentário
 
fxsaber:

Não será, pois não é forte.


Primeiro, o TS é escrito para o testador, onde as condições comerciais são ideais. Se tudo estiver bem, então eles tentam escrever a versão ao vivo de tal forma que ela esteja o mais próxima possível do que eles vêem no testador. Quaisquer outras abordagens para escrever o TS são o acerto ou erro, não a algoritmização da idéia.

Então aqui está a questão fundamental, qual é a situação de combate mais próxima a um testador? Eu expressei minha opinião (e dei um exemplo), eu ouvi a sua.

Enfrento a tarefa de traduzir a lógica comercial de um Expert Advisor desde o teste de tick-testing no testador de estratégia (MT4) até seu trabalho em uma conta real.

Meu raciocínio:

No testador, o Expert Advisor trabalha não apenas em condições ideais de negociação, mas na verdade em outro modo - em tempo real, ou seja, tem tempo para calcular o TS, e enviar uma ordem e obter sua resposta em um único tick, mas não é assim na negociação real. Parece que temos uma espécie de dois robôs diferentes - um de tempo real e outro de nenhum tempo. Se enviarmos/modificarmos uma ordem (mesmo uma!) para uma conta real = ping + tempo de execução, etc. = na melhor das hipóteses 100-500ms, e durante este tempo os ticks vão e precisam ser contados - e nós ficamos de pé, esperando... e então entramos no fluxo ao acaso (para onde o preço foi durante este tempo em relação às médias do nosso carrapato que não conhecemos). + devemos ter perdido alguns dos carrapatos mais rápidos e geralmente mais importantes). Portanto, como resultado, pode não restar nada da estratégia que executamos no testador.

Portanto, pensando bem, cheguei ao seguinte:

  1. No modo de batalha, a lógica comercial no Expert Advisor é desativada, e funciona, de fato, como um seguidor.
  2. O sistema comercial é movido para o indicador e gera comandos de abertura e fechamento, e não espera que o especialista execute esses comandos, mas simplesmente executa o TS que possui em condições ideais, quase como no testador. Tanto quanto sei, o indicador não deve pular carrapatos, embora duvide que seja tecnicamente possível - mas pelo menos deve ignorá-los menos do que o Consultor Especialista, onde esta possibilidade foi inicialmente descrita em sua documentação. + Mesmo à custa da separação dos erros de cálculo do TC deve ser menor, pois não há interrupções para todos os tipos de operações secundárias em relação à lógica do TC.
 
zenz:

Por isso, pensando bem, cheguei ao seguinte:

  1. No modo de batalha a lógica comercial no Expert Advisor é desativada e funciona, de fato, como uma máquina de cópia.
  2. O sistema de negociação é movido para o indicador e gera comandos de abertura e fechamento, e não está esperando que estes comandos sejam executados pelo Expert Advisor, mas simplesmente executa o TS em condições ideais, quase como em um testador. Tanto quanto sei, o indicador não deve pular carrapatos, embora duvide que seja tecnicamente possível - mas pelo menos deve ignorá-los menos do que o Consultor Especialista, onde esta possibilidade foi inicialmente descrita em sua documentação. + Mesmo às custas da separação de erros no cálculo de TC deve ser menor, pois não há interrupções para todos os tipos de secundários à lógica das operações de TC.

Sim, eu utilizo a mesma abordagem - uma espécie de testador ideal interno com suas próprias ordens abertas e uma copiadora que tenta materializar essas ordens virtuais. Este esquema contorna muito facilmente muitos problemas graves.


No MT5 é mais fácil porque podemos solicitar o histórico do tick lá. E você pode solicitá-lo para vários símbolos.

 
Stanislav Korotky:

Não se trata de tempo, trata-se de lógica (sobre o tempo - que está em outro fio ;-) ). Sua lógica (e minha lógica, pois concordo com tudo, inclusive com a analogia do carro) é fazer a análise do ambiente "de uma só vez e em uma só peça", em vez de de forma fragmentária. O processamento de quaisquer efeitos colaterais é adiado para a próxima execução, pois estes efeitos serão incorporados ao novo ambiente comercial.

Bem, se não houvesse correção de tempo, então ambas as lógicas (minha e do fxsaber) seriam idênticas - todos os pedidos seriam processados em cada tick mesmo após vários erros.

O objetivo é precisamente aproximar a realidade com execução não instantânea do modelo ideal obtido nos testes.

 
fxsaber:

Sim, eu utilizo a mesma abordagem - uma espécie de testador ideal interno com suas ordens abertas e uma copiadora que tenta materializar essas ordens virtuais.

Se você se materializar com sua abordagem (em loop, permanecendo na primeira ordem até que ela se sincronize com a realidade com sucesso), você pode se deparar com o mesmo problema de as demais ordens serem perdidas de vista (ou simplesmente serem processadas mais tarde). Mas isto é mais ou menos o mesmo, supostamente concluído, tópico).

 
Andrey Khatimlianskii:

Se você se materializar com sua abordagem (em loop, permanecendo na primeira ordem até que ela se sincronize com a realidade com sucesso), você pode se deparar com o mesmo problema de as demais ordens serem perdidas de vista (ou simplesmente serem processadas mais tarde). Mas esta é sobre a mesma questão que supostamente foi resolvida).

É assim que nós negociamos!

 
fxsaber:

Estamos esperando por um exemplo do OOP. E eu ainda o vejo como a mesma espinha dorsal na forma de um laço. A lógica não mudará porque primeiro será para determinar o que deve ser mudado, e depois para as decisões que já tomamos.

Não vou escrever um exemplo específico para esta tarefa. Mas você pode ver um conceito simplificado da abordagem em meu blog. Lá a fila não é analisada em profundidade, mas apenas verificada quanto ao vazio. Aqueles que desejarem podem melhorá-la.

Se por lógica entendemos a tarefa de "modificar uma pilha de pedidos devido à mudança de preços", existe apenas uma tarefa. A questão é o que é mais importante: modificar todos os pedidos ou modificá-los para se adequarem aos preços mais recentes? Dependendo de suas preferências, a lógica será diferente. Um simples loop garantiria que todos os pedidos fossem modificados, e eu sou a favor desta opção. Como já foi dito, o OOP fornece uma divisão clara da tarefa em blocos de responsabilidade e, com base nesta decomposição, "todas as encomendas" é mais importante do que "a relevância do preço". Isto é claro até mesmo pelo fato de que os preços mudam o tempo todo, e os pedidos só existem ocasionalmente. Eles são mais importantes.

 
Stanislav Korotky:

A OLP fornece clareza na divisão da tarefa em blocos de responsabilidade, e com base nesta decomposição "todas as ordens" são mais importantes do que "a relevância do preço".

Com base nesta decomposição, apenas a divisão segue. A "relevância do preço" nesta OLP é alcançada ao se estabelecer um lugar na fila de espera.
 
fxsaber:
Com base nesta decomposição, segue-se apenas a separação. A "relevância do preço" sob este OOP é alcançada ao estabelecer um lugar na fila de espera.

Isto agora é um pouco de "filosofia". O processamento é por fila de pedidos e não por fluxo de carrapatos, como sugerido na alternativa. De qualquer forma, estou me retirando desta discussão. Todos os argumentos já foram apresentados.

 
Stanislav Korotky:

De qualquer forma, estou me retirando desta discussão. Todos os argumentos já foram apresentados.

Já há uma tendência a acabar com isso.

 
fxsaber:

Abaixo abordaremos um assunto que diz respeito não apenas ao MT4, mas também ao MT5 com outras plataformas. Mas a lógica será escrita em MQL4 para facilitar a percepção, portanto, neste ramo.

Na maioria das vezes a espinha dorsal (a carne de qualquer pedido) de modificação/eliminação de pedidos se resume à seguinte lógica

Agora, a abordagem é rara, mas muito mais correta

Após o envio de uma ordem comercial, o ambiente comercial muda, portanto é aconselhável executar toda a lógica comercial do TS a partir do zero imediatamente após a resposta do servidor comercial.

O looping é um dos mais perigosos truques de programação. Provoca erros estranhos, raramente ocorrendo, que são quase impossíveis de analisar.

Ao invés de looping, você deveria, ao contrário, tentar terminar o fio do usuário o mais rápido possível. Se você quiser manter sua mão no pulso - analise a OnTradeTransaction no MT5. O MT4 geralmente não é adequado para tais circuitos, porque a simplicidade é, como dizem, pior que o roubo.

1234567891011...15
Novo comentário