Organizar el ciclo de pedidos - página 2
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
Porque el precio se moverá, y en cada nueva llamada a OnTick, se cumplirá la condición de una nueva modificación de la misma orden, la primera de la lista. Sobre todo si la modificación dura 5 segundos ;)
De nuevo, se toca la cuestión de la relevancia. Una orden siempre estará al día. Los demás estarán al día. Su variante, en cambio, no está actualizada en todos los órdenes.
Esta "columna vertebral" rompería la lógica de un EA que trabaja con más de una orden.
¿Qué sentido tendría si no diera ninguna ventaja a los sistemas con un orden y estropeara el resto?
Me encantaría entender lo que quieres decir, pero no puedo. No veo el problema con el principio de "si el tiempo de espera ha pasado, actualiza el entorno comercial".
Clasificar por volumen y/o distancia del precio antes de tratar los pedidos es lo correcto. Pero no debemos asumir que todos los que copien el código del foro lo aplicarán.
En ese sentido, mi código es más seguro.
Bueno, no fue escrito para los novatos. Tú y yo lo discutimos muy bien aquí: no hay agua.
De nuevo se plantea la cuestión de la relevancia. Una orden siempre estará al día. Los demás estarán al día si es posible. Su opción es que todos los pedidos no están al día.
Actual - ¿por cuánto?
Me alegro de entender lo que quieres decir, pero no funciona. No veo ningún problema con el principio de "si el tiempo de espera ha pasado, actualiza el entorno comercial".
Su algoritmo se fija en el primer orden de la lista, eso es todo.
En algunas situaciones esto puede ser perjudicial para el sistema (me lo he encontrado en la práctica).
Actual - ¿por cuánto?
En mi escenario, ambos SL se habrían modificado en 1,2375 o, en el peor de los casos, en 1,2374. Resultado final: +30 pips en ambas órdenes.
En cada paso de su ejemplo, la ST debería saber dónde deben estar sus órdenes sin ninguna orden de negociación. Es decir, la ST no puede estar vinculada de ninguna manera al lugar donde se encuentran sus órdenes ahora. Sólo se ocupa de calcular dónde deben situarse y de sincronizar el entorno comercial con lo que ha calculado a través de las órdenes comerciales.
En tu ejemplo, sin embargo, el resultado del TS depende de si OnTick ha llegado al precio alto o no. Y el TS correcto debería estar exactamente a la altura. Ella ve que ese precio lo fue (incluso si el OnTick con él se perdió), y por lo tanto sus SLs deben ser colocados en consecuencia. Y la sincronización hará su trabajo al 100%.
Y no entiendo por qué sigues diciendo que el segundo está parado. Incluso sin la lógica de sincronización se modificará de la misma manera que en su variante. No es que se llame a OnTick en el evento NewTick, sino como una función interna normal.
En cada paso de su ejemplo, la ST necesita saber dónde deben estar sus órdenes sin ninguna orden comercial. Es decir, la ST no puede estar vinculada de ninguna manera a dónde están las órdenes ahora. Sólo se ocupa de calcular dónde deben situarse y de sincronizar el entorno comercial con lo que ha calculado a través de las órdenes comerciales.
Lo hace, lo sabe. Pero no tiene tiempo de sincronizarla: mientras pasa una modificación, el precio se mueve más y una nueva condición calculada le dice que modifique de nuevo la primera orden. Y esto sucede todo el tiempo.
En tu ejemplo, el resultado de TC depende de si OnTick ha llegado al precio alto o no. Y el TS correcto debería estar exactamente antes de eso. Ella ve que ese precio lo fue (incluso si el OnTick con él se perdió), lo que significa que sus SLs deben ser colocados en consecuencia. Y la sincronización hará su trabajo al 100%.
No lo hace (en el ejemplo no se calculó el nivel de SL).
Y la sincronización no hará el trabajo, ya que no tendrá tiempo (ver arriba).
Y no entiendo por qué sigues diciendo que el segundo se queda parado. Incluso sin la lógica de sincronización se modificará de la misma manera que en su variante. No es que se llame a OnTick en el evento NewTick, sino como una función interna normal.
Como siempre, lo entendí.
Sin embargo, el precio ya ha cambiado mientras el proceso de modificación está en marcha y la llamada forzada de OnTick ya funciona con el nuevo precio, mientras que la segunda orden permanece en su nivel inicial.
No hay ningún error. Quizás demasiado específico para tu situación (pero de nuevo, bastante real, de la vida).
Lo hace, lo sabe. Pero no tiene tiempo de sincronizarse: mientras pasa una modificación, el precio se mueve más, y el nuevo estado calculado le dice que vuelva a modificar la primera orden. Y esto sucede todo el tiempo.
El ejemplo que has inventado no nos da pérdidas adicionales considerando esta lógica. Ahora déjame darte un ejemplo.
Supongamos que hacemos un trailing BuyLimits tras el movimiento al alza para abrir en el pullback necesario. Casi Lucky-TC. Si arrastramos una montaña de limitadores cada vez, no cogeremos un pullback con su opción.
Bueno, es extraño dar órdenes de comercio basadas en un entorno comercial obsoleto. Pero usted se obstina (como yo) en defender un punto de vista diferente.
Bueno, es extraño dar órdenes de comercio basadas en un entorno comercial obsoleto. Pero usted se obstina (como yo) en defender un punto de vista diferente.
Hay que elegir el menor de los males.
Por supuesto, el ejemplo con el límite que se extiende detrás del precio es mejor implementarlo en la variante "1 EA = 1 orden en cada dirección".
Pero, en general, es mejor mantener todos los pedidos bajo control.
Pero en general es más correcto mantener todas las órdenes bajo control.
Es decir, no está de acuerdo con la exigencia de que la ST trabaje sólo con el entorno comercial actual.
Es decir, no está de acuerdo con la exigencia de que la ST funcione sólo con el entorno comercial actual.
Si para ello hay que sacrificar el control de todas las órdenes del TC, absolutamente.
Imagínese: tiene una flota de cuatro camiones. Cada uno de ellos lleva una valiosa carga del punto A al punto B. Hay que vigilar la ruta.
¿Qué prefieres: estar en contacto cada minuto con uno de ellos, o cada 2 minutos con todos?
En el segundo caso, el retraso será algo mayor, y es posible que los cuatro tengan que tomar un ligero desvío si no consigues encaminarlos a tiempo. Pero en general será mejor para el negocio que tener un camión y perder los otros tres.
Si hay que sacrificar el control de todas las órdenes del TC para hacerlo, absolutamente.
Imagínese: tiene una flota de 4 camiones. Cada uno de ellos lleva una valiosa carga del punto A al punto B. Tienes que controlar la ruta.
¿Prefieres estar en contacto cada minuto con uno de ellos, o cada 2 minutos con todos?
En el segundo caso, el retraso será algo mayor, y los cuatro pueden tener que dar un pequeño rodeo si no consigues encaminarlos a tiempo. Pero en general será mejor para el negocio que gastar un camión y perder los otros tres.
+1.
Tal vez la nueva idea no habría surgido con el enfoque OOP, en el que un análogo de bucle con fuerza bruta de orden se esconde en alguna entidad tipo gestor que, en lugar de llamar directamente a OrderModify, genera una orden de modificación (con todos los parámetros) y la pone en una cola que luego se procesa. La idea es dividir la responsabilidad (que en este código está metida en un solo bucle) entre una entidad que analiza el entorno y una entidad que realiza acciones basadas en el análisis.
Tal vez esta idea no surgiría con el enfoque OOP, cuando un análogo del bucle con la búsqueda de órdenes se esconde en alguna entidad como el gestor, que en lugar de llamar a OrderModify directamente genera la orden de modificar (con todos los parámetros) y la pone en una cola, que luego se procesa. La idea es dividir la responsabilidad (que en este código está metida en un solo bucle) entre un objeto de análisis del entorno y un objeto de realización de acciones basadas en el análisis.
La única forma de evitar esta situación es utilizar órdenes asíncronas.
De lo contrario, seguiría existiendo un bucle sobre la lista de órdenes a ejecutar, que es, de hecho, un bucle sobre las órdenes.
Sólo en una situación de cola habría que tomar disposiciones para sustituir una orden antigua no ejecutada relacionada con una orden más reciente. De lo contrario, la cola podría desbordarse y los pedidos se enviarían fuera de la cola - obsoletos.