Organizar el ciclo de pedidos - página 3
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
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 transporta una valiosa carga del punto A al punto B. Hay que vigilar la ruta.
¿Qué prefieres: tener comunicación cada minuto - con uno de ellos, o cada 2 minutos - con todos ellos?
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.
Gracias por la asociación, pero no parece que tenga lógica comercial. La cuestión parece ser fundamental y afecta a principios muy diferentes de la construcción del TC.
La única forma de evitar esta situación sería utilizar órdenes asíncronas.
De lo contrario, seguiría existiendo un bucle en la lista de comandos a ejecutar, que es esencialmente un bucle en las órdenes.
Sólo en una situación de cola, tendrí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 enviados fuera de la cola serían obsoletos.
Gracias por la asociación, pero no parece que sea una lógica comercial. La cuestión parece ser fundamental y afecta a principios completamente diferentes de la construcción del TC.
Estoy dispuesto a escuchar a su asociación. Sí, la cuestión es fundamental.
No estoy de acuerdo. Una cola con retraso en la ejecución de los comandos ya da asincronía. No estamos ante un nuevo entorno en el bucle de mando. En efecto, sólo puede haber una orden en la cola para modificar un determinado pedido.
Solicitar un nuevo entorno, en general, lleva un mínimo de tiempo. La mayor parte se dedica a esperar una respuesta del servidor.
Puede delegar la ejecución de comandos a otro (o incluso a varios) EA, pero seguirá siendo una ejecución de comandos secuencial. No creo que el resultado sea diferente al del ciclo de pedidos incorporado.
Dispuesto a escuchar a su asociación. Sí, la cuestión es fundamental.
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 intentan escribir la versión en vivo de tal manera que sea lo más parecida posible 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? Yo he expresado mi opinión (y he puesto un ejemplo), la tuya es escuchada.
En primer lugar, el ST está escrito para el probador, donde las condiciones comerciales son ideales. Si todo va bien, entonces intentan escribir la versión en vivo para que en el mundo real 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.
Todavía no he oído por qué, en su opinión, cuando se trabaja con el primer orden de la lista, los resultados estarán más cerca del probador (todavía estamos discutiendo un sistema con múltiples órdenes).
Todavía no he oído por qué cree que los resultados se acercarán más al probador cuando se trabaje con el primer orden de la lista (todavía se está discutiendo un sistema de varios órdenes).
Y esto es casi un postulado más que una prueba, por desgracia. Como es su opción.
Sí, no hace falta retorcer un poco mi planteamiento, no se trata de la primera orden, se trata de reiniciar todo el TS después de cualquier pausa.
Y esto es casi un postulado más que una prueba, por desgracia. Ninguna de las dos es su opción.
Sí, no hace falta retorcer un poco mi planteamiento, no se trata de la primera orden, se trata de reiniciar todo el TS después de cualquier pausa.
Estoy de acuerdo, trabajar sólo con el primer orden sólo funcionará en determinadas circunstancias.
Creo que la discusión se ha agotado.
Creo que la discusión se ha agotado.
Sí, gracias. La forma en que se llevó a cabo la discusión fue muy diferente a las paralelas...
Solicitar un nuevo entorno suele llevar un mínimo de tiempo. La mayor parte se dedica a esperar una respuesta del servidor.
Puede delegar la ejecución de comandos a otro (o incluso a varios) EA, pero seguirá siendo una ejecución de comandos secuencial. No creo que el resultado sea diferente del bucle incorporado en las órdenes.
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 con el automóvil) 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.
Otro EA está descartado. Todo se puede hacer en uno. Y, por supuesto, el resultado será equivalente a un ciclo. Sólo entonces el código será lógicamente más comprensible y demostrará realmente nuestra lógica.
Otro EA está descartado. Todo se puede hacer en uno. Y por supuesto, el resultado será equivalente a un bucle. Es que entonces el código será lógicamente más claro y demostrará realmente nuestra lógica.
Estamos esperando un ejemplo OOP. Y lo sigo viendo 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.