Organizar el ciclo de pedidos - página 4
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
No lo será, ya que no es fuerte.
En primer lugar, el ST está escrito para el probador, donde las condiciones de negociación son ideales. Si todo va bien, entonces tratan de escribir la versión en vivo de tal manera que sea lo más parecido a lo que ven en el probador. Cualquier otra aproximación a la escritura de la ST es un acierto, no la algoritmización de la idea.
Así que aquí está la pregunta fundamental, ¿cuál es la situación de combate más cercana a un probador? He expresado mi opinión (y he puesto un ejemplo), he escuchado la tuya.
Me enfrento a la tarea de trasladar la lógica de negociación de un Asesor Experto desde la prueba de ticks en el probador de estrategias (MT4) a su trabajo en una cuenta real.
Mi razonamiento:
En el probador, el Asesor Experto funciona no sólo en condiciones ideales de negociación, sino también en otro modo - en tiempo real, es decir, tiene tiempo para calcular el TS, y enviar una orden y obtener su respuesta en un solo tick, pero no es así en el comercio real. Parece que tenemos una especie de dos robots diferentes : uno de tiempo real y otro de no tiempo. Si enviamos/modificamos una orden (¡incluso una!) a una cuenta real = ping + tiempo de ejecución, etc. = en el mejor de los casos 100-500ms, y durante este tiempo van los ticks y hay que contarlos - y nos quedamos parados, esperando... y luego entramos en el flujo al azar (donde el precio ha ido durante este tiempo en relación con nuestros promedios de garrapatas no sabemos. + debemos haber perdido algunos de los ticks más rápidos y normalmente más importantes). Así que, como resultado, puede que no quede nada de la estrategia que ejecutamos en el probador.
Por lo tanto, reflexionando, he llegado a lo siguiente:
Así que, reflexionando, he llegado a lo siguiente:
Sí, uso el mismo enfoque: una especie de probador ideal interno con sus propias órdenes abiertas y un copiador que intenta materializar esas órdenes virtuales. Este esquema evita muchos problemas graves con mucha facilidad.
En MT5 es más fácil porque allí podemos solicitar el historial de ticks. Y puede solicitarlo para varios símbolos.
No se trata de tiempo, se trata de lógica (sobre el tiempo - eso es en otro hilo ;-) ). Tu lógica (y la mía, ya que estoy de acuerdo con todo, incluida la analogía del coche) es hacer el análisis del medio ambiente "de golpe y porrazo", en lugar de hacerlo por partes. El procesamiento de cualquier efecto secundario se pospone hasta la siguiente ejecución, ya que estos efectos se incorporarán al nuevo entorno comercial.
Bueno, si no hubiera corrección de tiempo, entonces ambas lógicas (la mía y la de fxsaber) serían idénticas - todas las órdenes se procesarían en cada tick incluso después de varios errores.
El objetivo es precisamente aproximar la realidad con una ejecución no instantánea al modelo ideal obtenido en las pruebas.
Sí, uso el mismo enfoque: una especie de probador ideal interno con sus órdenes abiertas y un copiador que intenta materializar esas órdenes virtuales.
Si se materializa con su enfoque (en un bucle, permaneciendo en la primera orden hasta que se sincronice con la realidad con éxito), puede encontrarse con el mismo problema de que el resto de las órdenes se pierdan de vista (o simplemente se procesen más tarde). Pero esto es sobre el mismo tema, supuestamente terminado).
Si se materializa con su enfoque (en un bucle, permaneciendo en la primera orden hasta que se sincronice con la realidad con éxito), puede encontrarse con el mismo problema de que el resto de órdenes se pierdan de vista (o simplemente se procesen más tarde). Pero se trata de la misma cuestión que supuestamente se ha resuelto).
Así es como comerciamos.
Estamos esperando un ejemplo OOP. Y sigo viendo la misma columna vertebral en forma de bucle. La lógica no cambiará porque primero será para determinar lo que hay que cambiar, y luego para sobre las decisiones que ya hemos tomado.
No voy a escribir un ejemplo específicamente para esta tarea. Pero puedes ver un concepto simplificado del enfoque en mi blog. Allí la cola no se analiza en profundidad, sino que sólo se comprueba si está vacía. Aquellos que lo deseen pueden mejorarlo.
Si por lógica entendemos la tarea de "modificar una pila de pedidos debido a los cambios de precios", sólo hay una tarea. La cuestión es qué es más importante: ¿modificar todos los pedidos o modificarlos para que se ajusten a los últimos precios? Dependiendo de sus preferencias, la lógica será diferente. Un simple bucle garantizaría la modificación de todos los pedidos, y estoy a favor de esta opción. Como ya se ha dicho, la OOP proporciona una clara división de la tarea en bloques de responsabilidad, y en base a esta descomposición, "todos los pedidos" es más importante que la "relevancia del precio". Esto queda claro incluso por el hecho de que los precios cambian todo el tiempo, y los pedidos sólo están ahí ocasionalmente. Son más importantes.
La OLP aporta claridad al dividir la tarea en bloques de responsabilidad, y en base a esta descomposición "todas las órdenes" son más importantes que la "relevancia del precio"
Sobre la base de esta descomposición, sólo sigue la separación. La "relevancia del precio" en esta OOP se consigue fijando un lugar en la cola.
Esto ya es un poco de "filosofía". El procesamiento es por cola de órdenes y no por flujo de ticks como se sugiere en la alternativa. De todos modos, me retiro de esta discusión. Todos los argumentos ya han sido expuestos.
De todos modos, me retiro de esta discusión. Todos los argumentos ya han sido expuestos.
Ya hay una tendencia a terminar así.
A continuación vamos a tocar un tema que no sólo afecta a MT4, sino también a MT5 con otras plataformas. Pero la lógica se escribirá en MQL4 para facilitar la percepción, así que en esta rama.
La mayoría de las veces, la columna vertebral (la carne de cualquier orden) de la modificación/eliminación de órdenes se reduce a la siguiente lógica
Ahora, el enfoque es raro, pero mucho más correcto
Después de enviar una orden comercial, el entorno comercial cambia, por lo que es aconsejable ejecutar toda la lógica comercial del ST desde cero inmediatamente después de que el servidor comercial responda.
Los bucles son uno de los trucos de programación más peligrosos. Provoca errores extraños, que ocurren raramente y que son casi imposibles de analizar.
En lugar de hacer un bucle, debería, por el contrario, intentar terminar el flujo del usuario lo más rápidamente posible. Si quiere mantener el pulso - analice OnTradeTransaction en MT5. En general, MT4 no es adecuado para este tipo de bucles, porque la simplicidad es, como se dice, peor que el robo.