ORDER_POSITION_ID - página 21

[Vasiliy Sokolov]

Mikalas:

...

Pero quería implementarlo a través deórdenes (sucede que una orden parcialmente ejecutada "se mantiene" durante un par o tres de días),

...

¡Michael, tenías razón! ¿Por qué no lo hiciste? Tiene que entender que cuando se trata de posiciones netas, tarde o temprano se encontrará con el hecho de que no puede prescindir de analizar las órdenes incluidas en ella. Esto es lo que te digo como persona que lleva meses estudiando esta cuestión, y que ha cometido este error muchas veces:) Y además, si tienes más de un robot de trading, tienes que considerar la contribución de cada robot en la posición conjunta, y aquí tampoco puedes prescindir de las órdenes. Toda la información necesaria está disponible en las órdenes y en las operaciones basadas en ellas, y la agrupación de las operaciones en una única posición neta, por el contrario, elimina la información de forma irreversible.

Pero si usted basa su sistema en el análisis de las órdenes y las operaciones, debe considerar la ejecución parcial de las órdenes. Para ello, debe crear una versión virtual de la orden y controlar la llegada de nuevas operaciones. Mi algoritmo es el siguiente:

1. Se ha recibido un nuevo trato (el contador HistoryDealsTotal() ha cambiado).

2. Si esta operación es iniciada por una orden determinada, creamos una nueva orden que incluye una sola operación (COrder* order = new Order(deal)).

3. A continuación, buscamos en nuestra lista de pedidos virtuales ya existentes, un pedido con el mismo identificador. Si se encuentra dicha orden, entonces fusionamos las ofertas de la orden creada con las ofertas de la orden encontrada y actualizamos sus propiedades, y eliminamos la orden creada. Si el mismo pedido no está todavía en la lista, simplemente lo añadimos a la lista.

De este modo, el sistema se vuelve totalmente determinista. Con cada nueva operación nuestra orden virtual cambiará su estado, y no importa si la orden real está pendiente de ejecución o ya ha sido movida al historial, siempre la veremos en nuestro sistema en el volumen realmente ejecutado.

[Mikhail Filimonov]

Contender:
¿Y si cerramos la posición, y la parte no ejecutada de la orden no se elimina, se abrirá (o cambiará) otra posición?

¡Buena pregunta!

Si el pedido está activo, no aparece en el historial (esto se ha comprobado con seguridad),

Y por supuesto, una orden activa puede abrir otra posición, pero si

se volverá a ejecutar parcialmente, no le asignaremos ORDER_POSITION_ID.

En otraspalabras,ORDER_POSITION_ID sólo puede verse en el historial.

[Mikhail Filimonov]

C-4:

Sí, ocurre en la bolsa y hay que tener en cuenta estas situaciones. Esta es una de las desventajas fundamentales de las órdenes limitadas.

En tu ejemplo creo que podemos sustituirlo:

Para:

Como todas las operaciones de compra y venta se inician con algún tipo de orden.

No, no se puede, porque las operaciones se producen en la compensación, pero no tienen billete ( o más bien billete = 0 ),

pero tienen un precio y un tipo (COMPRA y VENTA) y por supuesto IN y OUT :(

[Mikhail Filimonov]

C-4:

Mikhail, ¡y con razón! ¿Por qué no lo ha puesto en práctica? Tiene que entender que cuando se trata de posiciones netas, tarde o temprano se enfrentará al hecho de que no puede prescindir del análisis de las órdenes incluidas en él. Esto es lo que te digo como persona que ha pasado meses estudiando esta cuestión, y que ha cometido este error muchas veces:) Además, si tienes más de un robot de trading, tienes que tener en cuenta el beneficio de cada robot en la posición total, y aquí tampoco puedes prescindir de las órdenes. Toda la información necesaria está contenida en las órdenes y en las operaciones basadas en ellas, y al mapear las operaciones en una única posición neta la información se borra irreversiblemente.

Pero si usted basa su sistema en el análisis de las órdenes y las operaciones, debe considerar la ejecución parcial de las órdenes. Para ello, debe crear una versión virtual de la orden y controlar la llegada de nuevas operaciones. Mi algoritmo es el siguiente:

1. Se ha recibido un nuevo trato (el contador HistoryDealsTotal() ha cambiado).

2. Si esta operación es iniciada por una orden, creamos una nueva orden que incluye una sola operación (COrder* order = new Order(deal)).

3. A continuación, buscamos en nuestra lista de pedidos virtuales ya existentes, un pedido con el mismo identificador. Si se encuentra dicha orden, entonces fusionamos las ofertas de la orden creada con las ofertas de la orden encontrada y actualizamos sus propiedades, y eliminamos la orden creada. Si el mismo pedido no está todavía en la lista, simplemente lo añadimos a la lista.

De este modo, el sistema se vuelve totalmente determinista. El estado de nuestra orden virtual cambiará con cada nueva operación y no importa si la orden real está pendiente de ejecución o ya ha sido trasladada al historial, siempre la veremos en nuestro sistema en el volumen realmente ejecutado.

Vasiliy, he implementado todo ( no como tú, pero tampoco está mal), sólo quería reducir el tiempo de búsqueda...

[Vasiliy Sokolov]

Serj_Che:

Problema resuelto, relaciones arregladas )

Tengo una pregunta relacionada:

Es muy incómodo seleccionar una orden por ticket para ver sus propiedades, porque no importa en qué punto del historial o del mercado se encuentre la orden, y el ticket no cambiará.

Así que tenemos que buscar el orden tanto aquí como allí.

No sería más fácil hacer como en MT4: si seleccionamos una orden, no importa donde se encuentre.

Lo he leído en la Ayuda de MT4:

¿Qué te parece?

P.D. Espero que a Mihail no le moleste continuar este hilo, para no producir más nuevos.

Mikalas:

С-4, ¡es muy bueno que la discusión haya sido constructiva!

Así que necesito el precio "neto" de la posición para saber (en un mes, por ejemplo) cuál es mi beneficio.

...

En la función (la estoy usando ahora):

...

La pregunta es relevante, en general la API de MetaTrader5 es realmente de muy bajo nivel. Pero... La negociación en la bolsa tiene muchos matices: ejecución de la orden por medio de múltiples operaciones, operaciones emparejadas en una posición neta y transferencia de la misma a través de la compensación, abundancia de operaciones de corretaje, etc. Así que la API de MetaTrader5 (y la propia MT5) es tal, como debería ser cualquier terminal de intercambio.

Otra cuestión es que su API puede ser envuelta en un wrapper de alto nivel escrito en MQL5 y utilizar a través de él las funciones de más bajo nivel de MT5. Si tuviera el envoltorio, la tarea de cálculo de beneficios de Mihail se vería así

for(int i = 0; i < TransactionsTotal(); i++)
{
    if(TransactionSelect(i, SELECT_BY_POS, MODE_TRADES))
    {
         ENUM_TRANS_TYPE trans_type = TransactionType();
         if(trans_type == TRANS_HEDGE_POSITION)
         {
              if(HedgePositionGetInteger(HEDGE_POSITION_MAGIC) != myMagic)continue;  // Работаем только со своими позициями.
              if(HedgePositionGetString(HEDGE_POSITION_SYMBOL) != Symbol())continue; // Работаем только с позициями на своем инструменте.
              double profit = HedgePositionGetDouble(HEDGE_POSITION_PROFIT_POINTS); //Профит в пунктах
              double currency = HedgePositionGetDouble(HEDGE_POSITION_PROFIT_CURRENCY); //Профит в валюте депозита.
              double price_open = HedgePositionGetDouble(HEDGE_POSITION_PRICE_OPEN); //Фактическая цена открытия позиции без клирингов и пр. изменений.
              double sl = HedgePositionGetDouble(HEDGE_POSITION_SL); //Узнаем уровень стоп-лосса позиции, если он есть, если нет - вернет нормализованный 0.0.
              if(HedgeOrderSelect(ORDER_SELECTED_INIT)) //Выбираем ордер, открывающий текущую позицию.
              {
                 int deals = HedgeOrderGetInteger(HEDGE_ORDER_DEALS_TOTAL); //Получаем количество сделок, открывающего ордера.
              }
              // Ну и так далее...
         }   
    }
}

[Vasiliy Sokolov]

Mikalas:

No, no se puede, porque las operaciones se producen en la compensación, pero no tienen billete ( o más bien billete = 0 ),

pero tienen un precio y un tipo (COMPRA y VENTA) y por supuesto IN y OUT :(

Mierda, claro:

Entonces, tristeza para ti.

[Vasiliy Sokolov]

Mikalas:
Vasiliy, he implementado todo ( no como tú, pero tampoco está mal), sólo quería reducir el tiempo de búsqueda...

Por cierto, ¿cómo se manejan las entradas multidireccionales de los robots? Después de todo, la entrada al mercado de un Asesor Experto puede ser la salida de otro robot.

[Vasiliy Sokolov]

Mikalas:

¡Buena pregunta!

Si el pedido está activo, no aparece en el historial (esto se ha comprobado con seguridad),

Y por supuesto, una orden activa puede abrir otra posición, pero si

se volverá a ejecutar parcialmente, no le asignaremos ORDER_POSITION_ID.

En otraspalabras,ORDER_POSITION_ID sólo puede verse en el historial.

Aquí hay otro problema. Una parte de las operaciones ejecutadas por esta orden pertenecerá a una posición, y la otra parte ya pertenecerá a la otra posición nueva. Entonces la pregunta es: ¿qué identificador de posición se le asignará, cuando finalmente llegue al historial?

[Mikhail Filimonov]

C-4:
Por cierto, ¿cómo se manejan las entradas multidireccionales de los robots? Después de todo, la entrada de un Asesor Experto en el mercado puede ser una salida de la posición de otro robot.

No tengo ninguna coincidencia.

[Mikhail Filimonov]

C-4:
El problema es diferente aquí. Parte de las operaciones ejecutadas de esta orden pertenecerán a una posición, y la otra parte ya pertenecerá a otra posición nueva. Entonces la pregunta es: ¿qué identificación de posición se le asignará cuando llegue a la historia?

Una orden completamente ejecutada, recibirá el ID de la posición que abrió o modificó.

Pero esto sólo estará disponible ( ID ) en el historial.