Preguntas de un "tonto" - página 176

[Yedelkin]

Karlson:

3Б. Cerrar parcialmente abriendo una media venta - OUT.

Lástima :/ Resulta que puede haber varias operaciones en el historial con la propiedad OUT, mientras que la posición seguirá existiendo.

[Anatoli Kazharski]

Yedelkin:
Malo :/

¿Por qué malo? Es sencillo, si te entiendo bien. Si es OUT y hay una posición, entonces hubo una reducción de volumen. Si es OUT y no hay posición, entonces la posición se cerró completamente.

[Yedelkin]

tol64:
¿Por qué es malo? Todo es sencillo, si te he entendido bien. Si hay una posición y OUT, hubo una disminución del volumen. Si está OUT y no hay posición, entonces la posición se cerró completamente.

Lo malo es esto. Su planteamiento"Si se sale y hay una posición, se ha reducido el volumen. Si no hay OUT y no hay posición, entonces la posición se ha cerrado completamente" tiene una característica que me parece engorrosa, a saber, la necesidad de comprobar adicionalmente la información sobre la posición en la base de datos del terminal cada vez.

Todos sabemos que la información en el terminal base llega con cierto retraso en relación con la situación real. Por lo tanto, no podemos excluir situaciones en las que el resultado de la comprobación es"hay una posición y está OUT", pero en realidad la posición se ha cerrado completamente. En otras palabras, es posible obtener información inexacta y utilizarla como base para tomar medidas erróneas. O habrá que inventar comprobaciones adicionales, retrasos o lo que sea conveniente.

Pero puedes prescindir de todos estos trucos. En particular, sin comprobar la disponibilidad de puestos. Para ello, basta con dejar una correspondencia uno a uno entre el cierre de la posición y la propiedad DEAL_ENTRY_OUT (correspondencia - tal como se presenta ahora en el Manual), y asignar la reducción del volumen de la posición en una propiedad separada de la transacción. Entonces bastará con encontrar en el historial (HistorySelectByPosition) un solo trato con la propiedad DEAL_ENTRY_OUT, y tener la seguridad de que la posición no se reduce, sino que se cierra exactamente, y que en ningún caso se puede revertir.

[Anatoli Kazharski]

Yedelkin:

Lo malo es esto. Su planteamiento"Si se sale y hay una posición, se ha reducido el volumen. Si no hay OUT y no hay posición, entonces la posición se ha cerrado completamente" tiene una característica que me parece engorrosa, a saber, la necesidad de comprobar adicionalmente la información sobre la posición en la base de datos del terminal cada vez.

Todos sabemos que la información en el terminal base llega con cierto retraso en relación con la situación real. Por lo tanto, no podemos excluir situaciones en las que el resultado de la comprobación es"hay una posición y está OUT", pero en realidad la posición se ha cerrado completamente. En otras palabras, es posible obtener información inexacta y utilizarla como base para tomar medidas erróneas. O habrá que inventar comprobaciones adicionales, retrasos o lo que sea conveniente.

Pero puedes prescindir de todos estos trucos. En particular, sin comprobar la disponibilidad de puestos. Para ello, basta con dejar una correspondencia uno a uno entre el cierre de la posición y la propiedad DEAL_ENTRY_OUT (correspondencia - tal como se presenta ahora en el Manual), y asignar la reducción del volumen de la posición en una propiedad separada de la transacción. Entonces bastará con encontrar en el historial (HistorySelectByPosition) una sola operación con la propiedad DEAL_ENTRY_OUT y saber con certeza que la posición no se reduce, sino que se cierra exactamente, y que en ningún caso puede revertirse.

En OnTrade(), recibimos la respuesta del servidor. Es decir, si comprobamos el evento en OnTrade(), ya sabremos con seguridad si hay una posición o no. Aunque podemos proporcionar opciones estándar como DEAL_ENTRY_FULLOUT (cierre completo) oDEAL_ENTRY_PARTOUT (cierre parcial) para que todo sea perfectamente elegante.)))

Mientras tanto, puedes hacer funciones separadas, para no tener que introducir "comprobaciones engorrosas" cada vez.

[Yedelkin]

tol64:

Aunque podría hacer opciones estándar como DEAL_ENTRY_FULLOUT oDEAL_ENTRY_PARTOUT para que todo sea perfectamente elegante.)))

De eso se trata. Ni siquiera tendremos que hacer comprobaciones adicionales en OnTrade, que parecerán demasiado engorrosas en comparación con la solución propuesta (FULLOUT / PARTOUT).

[Anatoli Kazharski]

Yedelkin:
Esa es la cuestión... Ni siquiera habría que hacer comprobaciones adicionales en OnTrade, lo que seguiría pareciendo engorroso en comparación con la solución propuesta (FULLOUT / PARTOUT).

Intenta hacer una propuesta al Servicio de Atención al Cliente. Tal vez lo consideren y algún día lo apliquen.

[Yedelkin]

tol64:
Intenta hacer una propuesta al Servicio de Atención al Cliente. Tal vez lo consideren y algún día lo apliquen.

Ya lo hice :) Como error lingüístico ...Vaya, me ha costado una hora componerlo.

[Anatoli Kazharski]

Yedelkin:
Ya lo hice :) Como un lapsus... Vaya, he tardado una hora en componerlo.

Todavía no se puede llamar un error. Pero qué puedes hacer ahora que ya te han enviado. ))

[Yedelkin]

tol64:
Todavía no se puede llamar un error. Pero qué puedes hacer ahora que te han enviado. ))

Bueno, aquí es donde las categorías de evaluación entran un poco en juego :) He intentado justificar la categoría de Errores :)

[Валерий]

Yedelkin:

Sí, cada periodo corresponde a un valor determinado. Alguien lo publicó en el foro hace un par de años. Puedes comprobarlo por ti mismo ejecutando una línea como la siguiente:

El script imprimirá los valores de ENUM_TIMEFRAMES para todos los períodos en sistema decimal:

void OnStart()
  {
//---
   for(int i=(int)PERIOD_CURRENT;i<=(int)PERIOD_MN1;i++)
     {
       ResetLastError();
       string period=EnumToString((ENUM_TIMEFRAMES)i);
       if(GetLastError())
        continue;
       Print(EnumToString((ENUM_TIMEFRAMES)i)+"="+IntegerToString(i));
     }
  }
//+------------------------------------------------------------------+