Hacer un servicio de certificación para los programadores ... - página 6

[Rustamzhan Salidzhanov]

Sí chicos....

ya se pueden dar puntuaciones :))))

[snowman]

VOLDEMAR:
Si no tienes nada bueno que decir, no digas nada o al menos habla de ello ..... Si supieras algo, me lo mostrarías... ¿O es demasiado malo? O no sabe nada ....

no hay nada que discutir.

En realidad, sería mejor peinar las funciones de envío de pedidos para comprobar que el pedido que se envía al servidor es correcto.

Me gustaría que el mensaje de error fuera antes del servidor, no después de recibir el error).

[Alexander Bereznyak]

MrGold166:

Ese es el punto del overshooting desde el final, no hay nada militar en procesar una orden dos veces. En el peor de los casos sólo nos impide si contamos las órdenes, por ejemplo el precio medio, una orden será contada 2 veces. Aunque interfiera fuertemente en los cálculos, en el siguiente tick todo volverá a su lugar y pondremos el take profit donde debe estar. En mi memoria con más de 50 órdenes y con el peor de los llamados "brokers" asiáticos (sí, ya sabéis a quién me refiero) nunca ha ocurrido esto después de que la cuenta fuera operada (ya sabéis por qué). Pero esto también puede evitarse:

int i,last_ticket;

for(i=OrdersTotal()-1;i>=0;i--) if(OrderSelect(i,SELECT_BY_POS) {

   if(OrderTicket()==last_ticket) continue;

   last_ticket=OrderTicket();

   }

Y cómo se puede garantizar que no se produzca la misma situación la próxima vez que se marque, sí nada.

Y el peor caso puede venir, que calcules mal la media y abras una orden mal y el siguiente tick no importe.

No es el número de órdenes lo que importa, sino el entorno de trading, la presencia de stops reales, la presencia de otros EAs en la cuenta.

[A100]

MrGold166:

Pero esto también puede evitarse:

int i,last_ticket;

for(i=OrdersTotal()-1;i>=0;i--) if(OrderSelect(i,SELECT_BY_POS) {

   if(OrderTicket()==last_ticket) continue;

   last_ticket=OrderTicket();

   }

En teoría, más de una orden podría cambiar de estado

[Alexander Bereznyak]

A100:
En teoría, el estado de más de una orden podría cambiar

Una buena idea, no pensé en dos, me quedé colgado en una.

Así que volvemos al principio, cómo resolver las colisiones con esta función.

[snowman]

sandex:

Buena idea, no pensé en dos, me quedé en una.

Así que volvemos al principio, cómo resolver las colisiones con esta función.

   int j=OrdersTotal();
   for(int i=j-1;i>=0;i--)
   {
      if(OrderSelect(i,SELECT_BY_POS))
      {
      }
   }
   if(j!=OrdersTotal())return(0);

En todo caso, vuelva a calcular si el número de órdenes de entrada y salida no son iguales.

[[Eliminado]]

A100:
Teóricamente, más de una orden podría cambiar

¿Y qué? Aunque todos cambien, no analizaremos los mismos oficios.

Si estamos hablando de un comercio que ha cambiado en la lista, entonces puede cambiar después de que hayamos pasado por la búsqueda - antes de poner el beneficio total.

[A100]

snowman:

En todo caso, vuelve a calcular si el número de órdenes de entrada y salida no es igual.

En el caso general incluso el número de órdenes puede ser igual, sólo que pueden ser órdenes diferentes

[[Eliminado]]

snowman:

Si el número de órdenes a la entrada y a la salida no es igual, vuelva a calcularlo.

Esto tampoco nos servirá si se abre una orden pendiente, se guardará la cantidad de órdenes pero no los parámetros. Por otro lado, esto apenas nos molestaría, si no hubiéramos incluido en el importe una orden pendiente recién abierta, no pasa nada. (Realmente no veo una situación en la que esto pueda causar un error). Esta situación sólo puede producirse en un conjunto especial de circunstancias, una de las cuales es que haya muchos ticks, es decir, que la próxima iteración sea muy próxima y se corrija el error. En caso de que el rebote de la orden se produzca entre ticks, esto no es un problema para nosotros.

A menudo vemos códigos de otros programadores en los que la enumeración se hace docenas de veces por iteración por separado para calcular un montón de parámetros y esto es un problema.

[A100]

MrGold166:

¿Y qué? Aunque todos cambien, no analizaremos los mismos oficios.

Si se trata de una operación de la lista que ha cambiado, entonces puede cambiar después de haber pasado por la búsqueda - antes de poner el beneficio total.

No me refería al cálculo aplicado a una situación concreta, sino al caso general. Creo que la doble contabilidad y/o la infravaloración sí son importantes, a veces de forma crítica