Organizando o ciclo do pedido - página 5

[fxsaber]

Vasiliy Sokolov:

O looping é uma das técnicas de programação mais perigosas. Provoca erros estranhos e infreqüentes que são quase impossíveis de analisar.

Pelo contrário, você deve tentar terminar um fio de usuário o mais rápido possível, em vez de fazer looping. Se você quiser ter uma "mão no pulso" - analise a OnTradeTransaction no MT5. O MT4 geralmente não é adequado para tais jogos, porque a simplicidade é pior do que o roubo, como se diz.

Não me referia a uma realização concreta, mas ao princípio do tremor de TS após qualquer pausa. Bem e onde há uma fixação terrível - não está claro. Como não está claro, por que há uma pressa para terminar um fio do usuário.

[Vasiliy Sokolov]

fxsaber:

Onde está o laço assustador lá - não está claro.

Chamar o OnTick da OnTick é um loop não trivial através da recursividade:

// Редкий, но правильный костяк модификации ордеров
for (int i = OrdersTotal() - 1; i >= 0; i--)
  if (OrderSelect(i, SELECT_BY_POS))
    if (OrderModify(OrderTicket(), Price, SL, TP, OrderExpiration()))     
    {
      i = OrdersTotal(); // Хотя бы так
      
      // А лучше так
      // OnTick(); break; // вместо строки выше лучше делать такой вызов (переполнения стека от рекурсивных вызовов быть не должно)
    }

Também não é claro por que existe uma pressa para terminar o fio do usuário.

Estamos trabalhando com um modelo orientado por eventos. Portanto, precisamos lidar com o evento atual o mais rápido possível para esperar pelo próximo. O tempo gasto na rosca é um buraco negro. Quanto mais tempo passarmos no fluxo, mais ultrapassado será o ambiente comercial com o qual estamos trabalhando.

[fxsaber]

Vasiliy Sokolov:

Chamar o OnTick da OnTick é um loop não trivial através da recursividade:

Aparentemente, esta é a única coisa que dissuade.

Estamos trabalhando com um modelo de evento. Portanto, precisamos lidar com o evento atual o mais rápido possível, a fim de esperar pelo próximo. O tempo gasto no fluxo é um buraco negro. Quanto mais tempo passarmos no fluxo, mais ultrapassado será o ambiente comercial com o qual trabalhamos.

Bem, isso não é verdade!

[Vasiliy Sokolov]

:

void OnTick()
{
   for(int i = 0; i < symbols.Total(); i++)
   {
      request.symbol = symbols.At(i); 
      OrderSendAsynch(request, result); // Начиная с этой строки, анализировать торговое окружение в текущем потоке не имеет смысла
                                        // Единственная верная стратегия - как можно быстрее завершить цикл, и выйти из OnTick
                                        // Для дальнейшего анализа например в OnTransaction
   }
}

s. Nós não nos entendemos de forma alguma. Não creio que possa haver qualquer diálogo entre nós.

[fxsaber]

Vasiliy Sokolov:
:

Onde você viu uma pausa em seu código, cuja simples presença é a única razão para agitar o TS a partir do zero? Você não o tem!

[Vasiliy Sokolov]

fxsaber:

Onde você viu uma pausa em seu código, cuja simples presença é a única razão para sacudir o TS do zero? Você não o tem!

Portanto, este código é uma ilustração do motivo pelo qual a linha atual deve ser encerrada o mais rápido possível. Você não deve sequer tentar solicitar o ambiente comercial na OnTick:

void OnTick()
{
   for(int i = 0; i < symbols.Total(); i++)
   {
      request.symbol = symbols.At(i); 
      OrderSendAsynch(request, result); // Начиная с этой строки, анализировать торговое окружение в текущем потоке не имеет смысла
                                        // Единственная верная стратегия - как можно быстрее завершить цикл, и выйти из OnTick
                                        // Для дальнейшего анализа например в OnTransaction      
   }
   // Далее торговое окружение начинает меняться. Мы не можем анализировать его в OnTick
   // Бессмысленно зацикливать OnTick дальше.
   // Результат работы этого кода будет неопределен
   Sleep(50);
   int total_1 = OrdersTotal();
   Sleep(50);
   int total_2 = OrdersTotal();
   //Результат операции не определен
   if(total_1 == total_2)
}

Uma vez que estamos no ponto em que as duas variáveis são comparadas, não podemos compará-las porque o ambiente continua mudando. Os valores em total_1 e total_2 ou não são mais iguais um ao outro, ou ambos são obsoletos, ou não contêm o número existente de pedidos, ou contêm os valores corretos. É inútil combater um ambiente comercial em mudança na OnTick, em vez disso, basta sair da OnTick, imediatamente após o loop for loop, e esperar por novos eventos indicando que o ambiente comercial mudou.

[fxsaber]

Vasiliy Sokolov:

Portanto, este código é uma ilustração do motivo pelo qual a linha atual deve ser encerrada o mais rápido possível. Você não pode sequer tentar consultar o ambiente comercial na OnTick:

Uma vez que estamos no ponto em que as duas variáveis são comparadas, não podemos compará-las porque o ambiente continua mudando. Os valores em total_1 e total_2 ou não são mais iguais um ao outro, ou ambos são obsoletos, ou não contêm o número existente de pedidos, ou contêm os valores corretos. É inútil lutar para mudar o ambiente comercial na OnTick, ao invés disso, só precisamos sair da OnTick, logo após o loop for loop, e esperar por novos eventos indicando que o ambiente comercial mudou.

Então por que você fez pausas?!

Mais uma vez, após qualquer pausa (deslizes ou ordens de negociação síncrona) TC deve ser abalada - a lógica de negociação deve ser iniciada a partir do zero. Assim, se forem usadas ordens de comércio assíncronas, as pausas mencionadas não ocorrem e há uma saída do evento-função esperando por um novo evento. Se não houver operações assíncronas, toda a lógica comercial pode até mesmo ser colocada em um roteiro em loop.

[Vasiliy Sokolov]

fxsaber:

Então por que você fez pausas?!

Mais uma vez, após qualquer pausa (deslizes ou ordens de negociação síncrona) o TS deve ser reiniciado - a lógica de negociação deve ser iniciada a partir do zero. Assim, se forem usadas ordens de comércio assíncronas, as pausas mencionadas não ocorrem e há uma saída do evento-função esperando por um novo evento. Se não houver operações assíncronas, toda a lógica comercial pode até mesmo ser colocada em um roteiro em loop.

Falarei de Thomas, e você falará de Yury. Em resumo, vamos terminar nosso diálogo. Continue a criar seus próprios scripts em loop. Sim, realmente funciona, mas não pode ser recomendado como um método de trabalho.

[fxsaber]

Estou interessado em saber sua opinião sobre esta situação na MT4, como eles lidam com isso?

O ToR do Expert Advisor é manter ordens pendentes e posições em aberto a uma certa distância fixa do preço atual em cada tick.

Deixe que as modificações do corretor demorem um pouco mais do que o intervalo de tempo médio entre os tiques de preço.

Assim, corremos em um ciclo reverso (na direção decrescente de SELECT_BY_POS) e fazemos a correspondente OrderModify.

Portanto, durante este loop, embalado no OnTick, pode acontecer o seguinte

1. EncomendasTotal pode aumentar (à mão, por exemplo, enchimentos abertos ou parciais).
2. Pode ocorrer uma re-indexação de ordens e posições pendentes (por exemplo, algumas ordens pendentes foram executadas durante o ciclo, ou algumas ordens pendentes foram apagadas manualmente, e algumas ordens pendentes foram colocadas em uma máquina com um ping curto).
3. 1º ou 2º ponto, mas nenhum erro OrderSelect e OrderModify ocorre. Apenas durante o ciclo por causa da p.1/2 alguns pedidos/posições acabarão faltando.

O que fazer?

A questão está relacionada indiretamente à discussão acima, mas não é para sua continuação (tópico encerrado). Preciso resolver algumas nuances não óbvias no MT4Orders para o MT5. Portanto, seria útil ouvir as opiniões sobre as situações descritas por aqueles que são bons na MT4 especificamente. E não sou o único que pode achá-lo útil.

Resolva o problema através do OnTimer - esta é provavelmente a primeira sugestão. Mas não precisamos dele - apenas da OnTick.

[Alexey Viktorov]

fxsaber:

Estou interessado em saber sua opinião sobre esta situação na MT4, como eles lidam com isso?

O ToR do Expert Advisor é manter ordens pendentes e posições em aberto a uma certa distância fixa do preço atual em cada tick.

Deixe que as modificações do corretor demorem um pouco mais do que o intervalo de tempo médio entre os tiques de preço.

Assim, corremos em um ciclo reverso (na direção decrescente de SELECT_BY_POS) e fazemos a correspondente OrderModify.

Portanto, durante este loop, embalado no OnTick, pode acontecer o seguinte

1. EncomendasTotal pode aumentar (à mão, por exemplo, enchimentos abertos ou parciais).
2. Pode ocorrer uma re-indexação de ordens e posições pendentes (por exemplo, algumas ordens pendentes foram executadas durante o ciclo, ou algumas ordens pendentes foram apagadas manualmente, e algumas ordens pendentes foram colocadas em uma máquina com um ping curto).
3. 1º ou 2º ponto, mas nenhum erro OrderSelect e OrderModify ocorre. Apenas durante o ciclo por causa da p.1/2 alguns pedidos/posições acabarão faltando.

O que fazer?

A questão está relacionada indiretamente à discussão acima, mas não é para sua continuação (tópico encerrado). Preciso resolver algumas nuances não óbvias no MT4Orders para o MT5. Portanto, seria útil ouvir a opinião sobre as situações descritas por aqueles que são bons no MT4 especificamente. E não sou o único que pode achá-lo útil.

Para resolver o problema através do OnTimer - esta é provavelmente a primeira sugestão. Mas deixemos isso de lado - apenas OnTick.

Em primeiro lugar, a situação é não-standard e muito poucas pessoas, se é que alguma vez a resolveram.

Pura e teoricamente:

Não temos que organizar um loop inverso para OrderModify, então que seja direto.

int i, total = OrdersTotal();
for(i = 0; i < total; i++)

Em seguida, vamos verificar as alterações da lista de pedidos

if(total != OrdersTotal())
 {
  i = 0;
  total = OrdersTotal();
  continue;
 }

Se a quantidade de pedidos mudou, recomeçaremos este ciclo com uma nova quantidade de pedidos.

Uma pergunta a mais:

fxsaber:

1. EncomendasTotal pode aumentar (à mão, por exemplo, enchimentos abertos ou parciais).
2. A re-indexação de ordens e posições pendentes pode acontecer (por exemplo, algumas ordens pendentes foram executadas durante um ciclo, ou algumas ordens pendentes foram apagadas manualmente, e algumas ordens pendentes foram colocadas em um ping curto).
3. 1º ou 2º ponto, mas nenhum erro OrderSelect e OrderModify ocorre. É que durante o ciclo devido à p.1/2 alguns pedidos/posições acabarão faltando.

É compreensível que se eles fossem acrescentados, eles ou outros não serão percebidos. Mas e se eles fossem simplesmente apagados? Não seríamos capazes de ir além da lista de pedidos?