Organizar el ciclo de pedidos - página 5

Nuevo comentario
 
Vasiliy Sokolov:

Los bucles son una de las técnicas de programación más peligrosas. Provoca errores extraños e infrecuentes que son casi imposibles de analizar.

Por el contrario, hay que tratar de terminar un hilo de usuario lo más rápido posible en lugar de hacer un bucle. Si quiere tener una "mano en el pulso" - analice OnTradeTransaction en MT5. En general, MT4 no es adecuado para este tipo de juegos, porque la simplicidad es peor que el robo, como se dice.

No me refería a una realización concreta, sino al principio de sacudida de la ST tras cualquier pausa. Bueno y donde hay una terrible fijación - no está claro. Como no está claro, por qué hay prisa para terminar un hilo de usuario.

 
fxsaber:

Así que donde está el bucle de miedo allí - no está claro.

Llamar a OnTick desde OnTick es un bucle no trivial a través de la recursión:

// Редкий, но правильный костяк модификации ордеров
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; // вместо строки выше лучше делать такой вызов (переполнения стека от рекурсивных вызовов быть не должно)
    }

Tampoco está claro por qué hay prisa por terminar el hilo de usuarios.

Trabajamos con un modelo basado en eventos. Por lo tanto, necesitamos manejar el evento actual tan rápido como sea posible para esperar el siguiente. El tiempo que se pasa en el hilo es un agujero negro. Cuanto más tiempo pasamos en el flujo, más anticuado es el entorno comercial con el que trabajamos.

 
Vasiliy Sokolov:

Llamar a OnTick desde OnTick es un bucle no trivial a través de la recursión:

Al parecer, esto es lo único que disuade.

Trabajamos con un modelo de eventos. Por lo tanto, necesitamos manejar el evento actual tan rápido como sea posible para esperar el siguiente. El tiempo que se pasa en el flujo es un agujero negro. Cuanto más tiempo pasamos en el flujo, más anticuado es el entorno comercial con el que trabajamos.

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

s. No nos entendemos en absoluto. No creo que pueda haber diálogo entre nosotros.

 
Vasiliy Sokolov:
:

¿Dónde ha visto una pausa en su código, cuya mera presencia es la única razón para sacudir el ST desde cero? ¡No lo tienes!

 
fxsaber:

¿Dónde has visto una pausa en tu código, cuya mera presencia es la única razón para sacudir el ST desde cero? ¡No lo tienes!

Así que este código es una ilustración de por qué el hilo actual debe ser terminado tan pronto como sea posible. Ni siquiera debería intentar solicitar el entorno comercial en 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)
}

Una vez que estamos en el punto en el que se comparan las dos variables, no podemos compararlas porque el entorno sigue cambiando. Los valores de total_1 y total_2 ya no son iguales entre sí, o ambos son obsoletos, o no contienen el número de pedidos existente, o contienen los valores correctos. No tiene sentido luchar contra un entorno comercial cambiante en OnTick, en su lugar, simplemente salga de OnTick, inmediatamente después del bucle for, y espere nuevos eventos que indiquen que el entorno comercial ha cambiado.

 
Vasiliy Sokolov:

Así que este código es una ilustración de por qué el hilo actual debe terminar lo más rápido posible. No se puede ni siquiera intentar consultar el entorno comercial en OnTick:

Una vez que estamos en el punto en el que se comparan las dos variables, no podemos compararlas porque el entorno sigue cambiando. Los valores de total_1 y total_2 ya no son iguales entre sí, o ambos son obsoletos, o no contienen el número de pedidos existente, o contienen los valores correctos. No tiene sentido luchar con el cambio de entorno comercial en OnTick, en su lugar, sólo tenemos que salir de OnTick, justo después del bucle for, y esperar nuevos eventos que indiquen que el entorno comercial ha cambiado.

¡¿Entonces por qué pusiste pausas?!


Una vez más, después de cualquier pausa (resbalones u órdenes de comercio sincrónico) TC debe ser sacudido - la lógica de negociación debe comenzar desde cero. En consecuencia, si se utilizan órdenes comerciales asíncronas, las pausas mencionadas no se producen y hay una salida de la función de eventos a la espera de un nuevo evento. Si no hay operaciones asíncronas, toda la lógica comercial puede incluso colocarse en un script en bucle.

 
fxsaber:

¡¿Entonces por qué pusiste pausas?!

Una vez más, después de cualquier pausa (resbalones u órdenes de negociación sincrónicas) el ST debe reiniciarse - la lógica de negociación debe comenzar desde cero. En consecuencia, si se utilizan órdenes comerciales asíncronas, las pausas mencionadas no se producen y hay una salida de la función de eventos a la espera de un nuevo evento. Si no hay operaciones asíncronas, toda la lógica comercial puede incluso colocarse en un script en bucle.

Yo hablaré de Thomas, y tú hablarás de Yury. En resumen, vamos a terminar nuestro diálogo. Sigue creando tus propios guiones en bucle. Sí, realmente funciona, pero no se puede recomendar como método de trabajo.

 

Me interesa saber su opinión sobre esta situación en MT4, ¿cómo lo manejan?


El ToR del Asesor Experto es mantener las órdenes pendientes y las posiciones abiertas a una cierta distancia fija del precio actual en cada tick.


Deje que las modificaciones del corredor tarden un poco más que el intervalo de tiempo medio entre los ticks del precio.


Por lo tanto, corremos en un ciclo inverso (en dirección decreciente de SELECT_BY_POS) y hacemos el OrderModify correspondiente.


Así, durante este bucle, empaquetado en OnTick, puede ocurrir lo siguiente

  1. PedidosTotal puede aumentar (a mano, por ejemplo, rellenos abiertos o parciales).
  2. Puede producirse una reindexación de las órdenes y posiciones pendientes (por ejemplo, algunas órdenes pendientes se ejecutaron durante el ciclo, o algunas órdenes pendientes se eliminaron manualmente, y algunas órdenes pendientes se colocaron en una máquina con un ping corto).
  3. 1er o 2º punto, pero no se produce el error OrderSelect y OrderModify. Sólo durante el ciclo debido a p.1/2 algunas órdenes/posiciones terminarán desapareciendo.

¿Qué hacer?

La pregunta está indirectamente relacionada con la discusión anterior, pero esto no es para su continuación (tema cerrado). Necesito resolver algunos matices no evidentes en MT4Orders para MT5. Así que sería útil escuchar las opiniones sobre las situaciones descritas de aquellos que son buenos en MT4 específicamente. Y no soy el único que puede encontrarlo útil.


Resolver el problema a través de OnTimer - esta es probablemente la primera sugerencia. Pero no lo necesitamos - sólo OnTick.

 
fxsaber:

Me interesa saber su opinión sobre esta situación en MT4, ¿cómo lo manejan?


El ToR del Asesor Experto es mantener las órdenes pendientes y las posiciones abiertas a una cierta distancia fija del precio actual en cada tick.


Deje que las modificaciones del corredor tomen un poco más de tiempo que el intervalo de tiempo promedio entre los ticks del precio.


Por lo tanto, corremos en un ciclo inverso (en dirección decreciente de SELECT_BY_POS) y hacemos el OrderModify correspondiente.


Así, durante este bucle, empaquetado en OnTick, puede ocurrir lo siguiente

  1. PedidosTotal puede aumentar (a mano, por ejemplo, rellenos abiertos o parciales).
  2. Puede producirse una reindexación de las órdenes y posiciones pendientes (por ejemplo, algunas órdenes pendientes se ejecutaron durante el ciclo, o algunas órdenes pendientes se eliminaron manualmente, y algunas órdenes pendientes se colocaron en una máquina con un ping corto).
  3. 1er o 2º punto, pero no se produce ningún error OrderSelect y OrderModify. Sólo durante el ciclo a causa de p.1/2 algunas órdenes/posiciones terminarán desapareciendo.

¿Qué hacer?

La pregunta está indirectamente relacionada con la discusión anterior, pero esto no es para su continuación (tema cerrado). Necesito resolver algunos matices no evidentes en MT4Orders para MT5. Así que sería útil escuchar la opinión sobre las situaciones descritas de aquellos que son buenos en MT4 específicamente. Y no soy el único que puede encontrarlo útil.


Para resolver el problema a través de OnTimer - esta es probablemente la primera sugerencia. Pero vamos a omitirlo - sólo OnTick.

En primer lugar, la situación no es estándar y muy pocas personas, si es que hay alguna, la han resuelto.

En pura teoría:

No tenemos que organizar un bucle inverso para OrderModify, así que deja que sea directo.

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

A continuación, vamos a comprobar los cambios de la lista de pedidos

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

Si la cantidad de pedidos ha cambiado, comenzaremos este bucle de nuevo con una nueva cantidad de pedidos.

Una pregunta más:

fxsaber:

  1. PedidosTotal puede aumentar (a mano, por ejemplo, rellenos abiertos o parciales).
  2. La reindexación de órdenes y posiciones pendientes puede ocurrir (por ejemplo, alguna orden pendiente fue ejecutada durante un ciclo, o algunas órdenes pendientes fueron eliminadas manualmente, y algunas órdenes pendientes fueron colocadas en un ping corto).
  3. 1er o 2º punto, pero no se produce el error OrderSelect y OrderModify. Es que durante el ciclo debido a p.1/2 algunas órdenes/posiciones terminarán desapareciendo.

Es comprensible que, si se añaden, se echen de menos ellos u otros. Pero, ¿y si simplemente se borran? ¿No podríamos ir más allá de la lista de pedidos?

123456789101112...15
Nuevo comentario