Consejos útiles para los participantes en el Campeonato - página 11

Nuevo comentario
 
VNIK писал (а):

Perdón por la pregunta indiscreta a los organizadores del Campeonato:

Cómo se gestionará la fiscalidad del premio (porque el importe de cada premio es muy grande):

¿Tendrá que pagar cada premiado su propio impuesto? (¿y a qué ritmo?) ¿O se centralizará? (es decir, los impuestos ya se tienen en cuenta...).

Sería una pena renunciar a la mitad del premio por los impuestos.

Estoy de acuerdo contigo, a mí también me daría pena dar la mitad de tu premio para pagar mis impuestos...
En realidad, es mejor no ganar nada para no sentir pena... .
 
VNIK:

Perdón por la pregunta indiscreta a los organizadores del Campeonato:

Cómo se gestionará la fiscalidad del premio (porque el importe de cada premio es muy grande):

¿Tendrá que pagar cada premiado su propio impuesto? (¿y a qué ritmo?) ¿O se centralizará? (es decir, los impuestos ya se tienen en cuenta...).

Sería una pena renunciar a la mitad del premio por los impuestos.


Sí, los premiados pagan sus propios impuestos; es una práctica habitual en los premios de todo el mundo.
 
No hay manera de probar si este cierre de órdenes funcionará siempre correctamente:
while (OrdersTotal()>0)
   {
      OrderSelect(0,SELECT_BY_POS);
      if (OrderType()==OP_BUY)       OrderClose(OrderTicket(),OrderLots(),Bid,3,Green);
      else if (OrderType()==OP_SELL) OrderClose(OrderTicket(),OrderLots(),Ask,3,Red);
      
      err=GetLastError();
      if (err==135 || err==138) RefreshRates();
   }
La pregunta es: si el código de error no es 135 o 138, ¿habrá un bucle? Si es así, ¿cómo se puede evitar esto, con la garantía de que las órdenes se cierren?
 
MAEstro:
No hay manera de probar si este cierre de órdenes funcionará siempre correctamente:
Aquí hay un error tras otro. He contado 4 errores y todos son catastróficos.
Vuelve a leer el artículo de consejos, por favor.
 
Recuerdo este consejo de memoria, pero parece que no sirve de mucho :(

Descuido flagrante del control de errores con el bucle
(Tengo control de errores, las órdenes pendientes no se utilizan, o debo hacer una condición de salida del bucle también? ¿Qué hacer entonces con la garantía de cierre de pedido? ¿O quizás no he procesado todos los códigos de error?

Falta de control de OrderSelect - procesos asíncronos en acción
(sí, ¡no compruebo lo que devuelve Order_Select! Digamos que si en este caso concreto devuelve false, ¿qué cambiará dentro del bucle, o qué será incorrecto? No estoy modificando el pedido, ¡lo estoy cerrando!)

Omisión de la función de actualización del entorno de mercado a través de RefreshRates()
(Creo que lo refresco, todo debería estar bien aquí)

¿Tal vez haya un código listo para cerrar TODOS los pedidos? Te agradecería que lo publicaras.

P.D. lo que Rosh sugirió http://www.alpari-idc.ru/ru/experts/articles/9.html , no garantiza el cierre de las órdenes.
 
Hay incluso 5 errores:
  1. El resultado de OrderSelect no se comprueba
  2. el resultado de OrderClose() no se comprueba explícitamente
  3. GetLastError() puede ser llamado sin ninguna operación comercial (por ejemplo, si se ha encontrado una orden pendiente)
  4. RefreshRates() no se llama siempre, sino sólo cuando hay un fallo - esto es un grave error
  5. si hay órdenes pendientes en la lista, se trata de un bucle al 100%
Como resultado: hay 5 errores en 9 líneas - el código sólo puede ser desechado.
 
Renat:
Hasta 5 errores:
  1. El resultado de OrderSelect no se comprueba
  2. el resultado de OrderClose() no se comprueba explícitamente
  3. GetLastError() puede ser llamado sin ninguna operación comercial (por ejemplo, si se ha encontrado una orden pendiente)
  4. ...
Como resultado: hay 5 errores en 9 líneas - el código sólo puede ser desechado.
¿Y por qué meterlo todo en un experto para la competición? ¿Para leer el registro?
El OrderSelect debe seleccionar y el OrderClose debe cerrar las órdenes necesarias.
Y no debería haber ningún error :-)
O a costa del cliente :-)
 
Renat писал (а):
Hay incluso 5 errores:
  1. OrderSelect no comprueba
  2. explícitamente
    3. el resultado
  3. OrderClose()
  4. GetLastError() puede llamarse sin ninguna operación comercial (por ejemplo, si se encuentra una orden pendiente)
  5. RefreshRates() no se llama siempre, sino sólo en caso de fallo - un grave error
  6. si la lista contiene órdenes pendientes, entonces 100% de bucle
Como resultado: hay 5 errores en 9 líneas - el código sólo puede ser desechado.

Objetivo: cerrar todos los pedidos con una garantía del 100%.
Restricciones: no se utilizan las órdenes pendientes

1. ¿Por qué debemos comprobar el resultado si tenemos que cerrar una orden? Si devuelve false, volverá a él en la siguiente pasada, ya que se utiliza un bucle while.
2. Véase el punto 1.
3. Para ello existe una comprobación de los códigos de error.
4. Si se actualiza siempre, no tiene sentido comprobar los errores :(
5. No hay pedidos pendientes

Todos los ejemplos de cierre de pedidos que he encontrado en mi búsqueda son de un solo paso y sólo funcionan si todo está bien con el servidor, no hay recotizaciones, etc. Y todos ellos conducen a que un día no se cierre una orden y obtengamos un buen beneficio... Si me equivoco, corrígeme o dame un enlace donde pueda convencerme de que estoy equivocado.

Por supuesto, soy muy consciente de que mi código puede dar lugar a un bucle, pero en mi opinión es mejor que el riesgo de no cerrar una orden, lo que podría dar lugar a graves pérdidas financieras.
Aunque sería mejor que todos los pedidos se cerraran con un 100% de garantía y no hubiera posibilidad de que un pedido merodeara, este es el código que me gustaría que me dieran =)

Aquí hay un código ligeramente modificado, que debería considerar incluso las órdenes pendientes:
while (OrdersTotal()>0)
   {
      OrderSelect(0,SELECT_BY_POS);
      if (OrderType()==OP_BUY)       OrderClose(OrderTicket(),OrderLots(),Bid,3,Green);
      else if (OrderType()==OP_SELL) OrderClose(OrderTicket(),OrderLots(),Ask,3,Red);
      else OrderDelete(OrderTicket());
      
      RefreshRates();
      err=GetLastError();
      if (err!=135 && err!=138 && err!=0) break;
   }

¿No es tan "temerario" como el anterior?
Sigo sin entender, ¿por qué comprobar OrderSelect y OrderClose en este caso?
 
Desgraciadamente, nadie da garantías sobre las operaciones comerciales. El código anterior es mucho mejor que el anterior.

OrderSelect debe estar siempre marcado, esto se indica explícitamente en los Consejos útiles:
  • Falta de control de OrderSelect - procesos asíncronos en acción


    Por lo general, un comerciante percibe su programa como una tarea única y exclusiva. Pero en realidad, hay una gran cantidad de cambios asíncronos en la cuenta de operaciones justo durante el funcionamiento del Asesor Experto. Las posiciones se modifican, se añaden y se eliminan. Si no se controla el resultado de cada llamada a OrderSelect(), puede ocurrir que en un momento dado el experto opere con datos erróneos (cero) y haga un movimiento equivocado.

 
Renat:
Por desgracia, no hay garantías en las operaciones comerciales. El código anterior es mucho mejor que el anterior.

OrderSelect debe estar siempre marcado, esto se indica explícitamente en los Consejos útiles:
  • Sin control de OrderSelect - procesos asíncronos en acción

    ... Los puestos se modifican, se añaden y se eliminan. ...

Supongamos que se modifica una posición. Hay una solicitud para seleccionar una orden por alguna condición. Se ha producido un error. ¿Qué puede cambiar? Las condiciones iniciales pueden no estar disponibles en el siguiente tick, así que ¿por qué debería cometer el mismo error de nuevo?
No hay comentarios sobre "añadido y eliminado" :-(
Por favor, dame un ejemplo de código que funcione usando OrderSelect para obtener OrderCloseTime.
1...45678910111213141516
Nuevo comentario