¿Es posible implementar una contabilidad fiable de la estructura de posiciones agregadas en MT5? - página 18
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Tus atrevidas afirmaciones en varias ocasiones (mis calificaciones, la situación del MC, etc.) reducen un poco el interés de tu opinión, ¿no crees?) De alguna manera, no tiene sentido responderte, ¿por qué responder a las declaraciones de una persona claramente inadecuada? )))
Para empezar, deja de confundir las alucinaciones con la realidad, ya hablaremos.
Ya está, me he calmado.
¿De qué vamos a hablar?
Ya tengo el bolígrafo y la libreta preparados.
>> Le escucho, señor.
Acabo de aclararlo. Dado que el nivel de SL no está garantizado de ninguna manera y se ejecuta en los mercados sólo a petición del mercado, entonces la obligación de no alcanzar el nivel de TP no es necesaria. Justo antes de ejecutar el SL en el mercado, el servidor de ejecución (Dukascopy) borra el nivel de TP (aunque esté en el pick). Este es el punto que, lamentablemente, no puede ser implementado por el operador en MT5, incluso si tiene una conexión perfecta con el servidor de comercio. Y es, efectivamente, REALMENTE IMPOSIBLE en la MT5.
Así es como vemos la solución a este problema:
se introduce un enlace (FILL->KILL) a nivel del servidor de trading de MT5 entre las órdenes de Límite y las de Stop, que da lo siguiente:
- Antes de realizar una orden Stop de cumplimiento de mercado, el servidor de ejecución elimina la orden de Límite asociada a la misma.
- Cuando se dispara una orden de límite, el servidor de ejecución elimina la orden de stop relacionada con ella.
Todos los problemas comentados se resuelven de forma muy sencilla: introduciendo órdenes condicionales en el servidor. Esto, por cierto, se hace en muchos corredores que trabajan según el esquema clásico de intercambio. Para ello, al establecer una orden, deberíamos añadir la posibilidad de establecer una orden vinculada para ser cancelada e introducida. La lógica es elemental: si se ejecuta la orden A, se colocan las órdenes B y C. Lo mismo ocurre con la cancelación: si se ejecuta la orden A, se cancelan las órdenes B y C. O viceversa: la orden B se cancela si la orden A ha llegado a la ejecución. Y entonces el problema del cálculo de la posición agregada se resuelve de forma elemental, así como el problema de la fijación y anulación de TP y SL. Además, ofrece muchas posibilidades adicionales.
Z.U. Después de escribir, he visto que getch ya lo ha mencionado en un post anteriormente. Sólo que no es necesario conectar sólo las órdenes de límite y stop. Si se puede vincular alguno, hay muchas más posibilidades.
Para: getch
Решение данной проблемы видится так:
вводится связь (FILL->KILL) на уровне торгового сервера MT5 между Limit-ордерами и Stop-ордерами, которая дает следующее:
- перед тем, как сделать маркет-сиполнение Stop-ордера, удаляется Execution-сервером связанный с ним Limit-ордер.
- после срабатывания Limit-ордера, удаляется Execution-сервером связанный с ним Stop-ордер.
Esto es difícil de hacer porque los pedidos tienen entradas diferentes.
Hay que introducir un campo más en el servidor y en el terminal,
y MQ no se decantará por un movimiento tan atípico.
TP y SL existen. Y qué si es una posición agregada.
Como dijo Integer, las paradas son el último recurso :-)
Para Avals:
Este tema no se trata de cómo, se puede hacer en absoluto.
Se puede hacer.
Este tema trata sobre la fiabilidad de la ejecución de órdenes con múltiples EAs y una posición agregada.
No es la opción más fiable.
Para: getch
Esto es difícil de hacer porque los pedidos tienen entradas diferentes.
Es necesario introducir un campo más en el servidor y en el terminal,
y MQ no se decantará por un movimiento tan poco habitual.
TP y SL existen. Y qué si se trata de una posición agregada.
Como dijo Integer, las paradas son el último recurso :-)
MQ y SL son lo mismo que getch))))) y es un paso 100% fiable y estándar implementado en la mayoría de los programas de corretaje
Todos los problemas comentados se resuelven de forma muy sencilla: introduciendo órdenes condicionales en el servidor. Esto, por cierto, se hace en muchos corredores que trabajan según el esquema clásico de intercambio. Para ello, al establecer una orden, deberíamos añadir la posibilidad de establecer una orden vinculada para ser cancelada e introducida. La lógica es elemental: si se ejecuta la orden A, se colocan las órdenes B y C. Lo mismo ocurre con la cancelación: si se ejecuta la orden A, se cancelan las órdenes B y C. O viceversa: la orden B se cancela si la orden A ha llegado a la ejecución. Y entonces el problema del cálculo de la posición agregada se resuelve de forma elemental, así como el problema de la fijación y anulación de TP y SL. Además, ofrece muchas posibilidades adicionales.
Z.U. Después de escribir, he visto que getch ya lo ha mencionado en un post anteriormente. Sólo que no es necesario conectar sólo las órdenes de límite y stop. Si puedes enlazar alguno, las posibilidades son mucho mayores.
Mi error, no lo he entendido. Es una buena idea. Una especie de mini guiones.
Pero el problema es que esto supone una carga aún mayor para el servidor que el almacenamiento de elementos no acumulables.
Culpa mía, no lo resolví. Es una buena idea. Una especie de mini guiones.
Pero el problema es que supone una carga aún mayor para el servidor que el almacenamiento de elementos no acumulables.
Así que el usuario seguirá introduciendo estas solicitudes. De hecho, todo es elemental y no consume recursos. Es una parte necesaria de cualquier plataforma. Por ejemplo, QUIKa tiene http://www.quik.ru/about/features/conditional-orders/.
Alpha-Direct lo tiene http://www.alfadirect.ru/help3_3/index.htm y otras plataformas de trading burguesas lo tienen. No recuerdo ningún terminal que no lo tenga.
Escribí lo mismo que getch)))) y es un paso 100% fiable y estándar implementado en la mayoría de los programas de corretaje
Hay más posibilidades gracias a las órdenes OCO comunes (los miniscripts más primitivos del servidor de operaciones). La bandera FILL->KILL en la MT5 parece ser suficiente. Algunas empresas (como StrategyRunner) han optado por almacenar scripts e incluso Asesores Expertos en sus servidores. Esta vía tiene sus ventajas (discutibles) y sus inconvenientes (discutibles). MetaQuotes ha tomado otro camino.
Las órdenes OCO comunes (miniscripts primitivos en el servidor comercial) ofrecen más oportunidades. La bandera FILL->KILL en la MT5 parece ser suficiente. Algunas empresas (como StrategyRunner) han optado por almacenar scripts e incluso Asesores Expertos en sus servidores. Esta vía tiene sus ventajas (discutibles) y sus inconvenientes (discutibles). MetaQuotes ha tomado otro camino.
Todavía no está muy claro qué camino han elegido)))