¿La desaceleración lineal es un error de programación o una característica de MT4? - página 11
![MQL5 - Lenguaje de estrategias comerciales para el terminal de cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Me gustaría saber quién es MetaQuotes, ¿puedo recibir un mensaje?
He echado un vistazo rápido al código. Inmediatamente me vino a la mente un pasaje del poema de Lermontov:
Ahora a su pregunta:
-Aleks-:
En la fase de perfeccionamiento de la estrategia, y sobre todo de la táctica, hay que encargar todo tipo de añadidos para probar la idea, en esta fase es bastante posible tolerar la lentitud del Asesor Experto.
Pero me sorprendió la velocidad 6 veces menor en comparación con la versión principal del EA. La optimización delajuste del EA es necesaria al menos para la recogida de datos analíticos.
¿Estoy en lo cierto al entender que es imposible leer el código de otras personas y que es mejor pedir otra versión del EA después de que obtengamos uno exitoso, pero debe ser escrito desde cero, y sólo en este caso, podemos estar seguros de la alta velocidad y la fiabilidad? Personalmente creo que la parte de la tarea del compilador es cortar las operaciones duplicadas, por ejemplo...
No me refiero a este código, sino a nivel global. ¿Así que refutas esta afirmación?Si usted encarga a un programador que escriba en el estilo de "caballos y personas mezcladas" - tiene que reescribir no dos o tres veces, sino todo el tiempo y siempre al 100%, por todo el aumento del presupuesto. Si hace un pedido a los profesionales, cambiar los requisitos en un 20%, 40% o incluso 80% no requerirá reescribir el código no sólo por completo, sino incluso en el mismo porcentaje de los cambios. Pero con un presupuesto de "<50 dólares" olvídate.
¿Estoy en lo cierto al suponer que debería haber un retraso artificial en el envío de órdenes a las órdenes abiertas, pero sin esperar la confirmación de que se han abierto?
Por supuesto, el Asesor Experto debe manejar cualquier error de envío de órdenes. En el caso más simple - para mostrar un mensaje sobre la apertura fallida de la orden. En la versión más avanzada, decidirá las acciones posteriores.
Así que necesito un EA que me sustituya, por lo que las acciones posteriores son muy relevantes... Pero no es seguro que lleguen a tiempo (por ejemplo, el precio ya se ha alejado mucho del punto de entrada calculado).
No dejó que se enviara. Pida al codificador que utilice IsTradeContextBusy para comprobarlo.
Gracias por el consejo, pero precisamente de estos matices hablaba en el siguiente hilo. ¿Cómo voy a saberlo?
Si estás usando la compilación 509, hay 8 hilos allí. La situación con IsTradeContextBusy no debería ocurrir.
Si lo hace, vea el punto anterior.
También puedes utilizar más de un terminal.
No entiendo, ¿el número de terminales afecta a la forma en que se pasa una orden? Es decir, podemos lanzar varios terminales para una misma cuenta y enviar una orden de apertura desde cada terminal y si la mitad de ellos se cierra, la otra mitad ejecutará la orden con éxito? Pensaba que la orden debe ser procesada por el DC y sólo entonces aceptar la siguiente...
He echado un vistazo rápido al código. Inmediatamente me vino a la mente un pasaje del poema de Lermontov:
Ahora a su pregunta:
Si encargas a un programador que escriba en el estilo "personas y caballos mezclados", tienes que reescribirlo no dos o tres veces, sino todo el tiempo y siempre al 100%, por el presupuesto cada vez mayor. Si hace un pedido a los profesionales, cambiar los requisitos en un 20%, 40% o incluso 80% no requerirá reescribir el código no sólo por completo, sino incluso en el mismo porcentaje de los cambios. Pero con un presupuesto de "<50 dólares" olvídate.
Ahora mismo me está costando más de 100 dólares y sé que voy a añadir más. Los cálculos son los siguientes:
10 revisiones a 30 dólares suponen un coste de 300 dólares, mientras que 10 a 50 dólares suponen un coste de 500 dólares. Ahorrar como 200 dólares es significativo para mí. Pero cuando esté contento con él, podré encargar un EA desde cero (eliminando las cosas innecesarias) y costará unos 80 dólares. Este enfoque se justifica por sí mismo, especialmente cuando el desarrollo está en marcha. Excepto por los nervios que tienes que gastar... pero la suerte ha querido que sea así.
Lo has entendido mal. No debe haber retrasos artificiales. MT5 tiene un modelo de eventos sencillo que debería utilizarse en lugar de los retrasos de sleep()
Gracias por el consejo, pero estos son los matices que comenté en el siguiente hilo. ¿Cómo debo conocerlas?
No necesito entrar en ellos y buscar algo.
Si alguien insinuó cómo debería ser, y encuentras una carencia en tu código, mejor cambia al codificador silenciosamente. No crear ramas.
No entiendo, ¿el número de terminales afecta a la forma en que se pasa una orden? Es decir, ¿se pueden poner en marcha varios terminales en la misma cuenta y enviar una orden de apertura desde cada uno de ellos, y si la mitad se atasca, la otra mitad ejecutará la orden con éxito?
El número de terminales será igual al número de hilos a enviar. 10 terminales enviarán 1 pedido - habrá 10 pedidos.
Así que necesito un EA que me sustituya, por lo que las acciones posteriores son muy relevantes... pero no es seguro que lleguen a tiempo (por ejemplo, el precio ya se ha alejado mucho del punto de entrada calculado).
De momento el Asesor Experto me cuesta más de 100 dólares y sé que iré añadiendo más. Así que esas son las matemáticas:10 revisiones a 30 dólares suponen un gasto de 300 dólares, mientras que 10 a 50 dólares suponen un gasto de 500 dólares. Ahorrar como 200 dólares es significativo para mí. Pero cuando esté satisfecho con él, podré encargar mi Asesor Experto desde cero (eliminando cosas innecesarias) y me costará 80 dólares. Este enfoque se justifica por sí mismo, especialmente cuando el desarrollo está en marcha. Excepto que tienes que desgastar tus nervios... pero es una cuestión de suerte.
Este es un enfoque equivocado por su parte.
Ordenas el código para el probador, adviertes sobre la importancia de la velocidad de optimización, haces las mejoras necesarias en él. Y sólo después de que la versión de prueba esté lista, usted pide la versión real con la lógica completamente probada y todas las modificaciones/recomendaciones.
Ahorrará mucho más dinero. ¿No?
No tienes que buscar en ellos y averiguar qué es lo que hay.
Si alguien insinuó cómo debería ser, y usted encuentra una falta de ella en el código - cambie silenciosamente al codificador. No crear ramas.
el número de terminales - la misma multiplicidad de hilos a enviar. 10 terminales enviarán 1 pedido - habrá 10 pedidos.
¿Y qué pasa con la empresa de corretaje? Al fin y al cabo, ¡es el terminal el que tiene una orden atascada! ¿Cuál es la razón para enviar una multitud de pedidos entonces?
Este es un enfoque equivocado por su parte.
Usted ordena el código para el probador, notificándole la importancia de la velocidad de optimización, e introduce en él las mejoras necesarias. Y sólo después de que la versión de prueba esté lista, pedir la versión real con la lógica completamente depurada y todas las modificaciones/recomendaciones necesarias.
Ahorrará mucho más dinero. ¿No?
Bueno, para empezar, no he sugerido inicialmente que la velocidad de las pruebas dependa mucho del probador o de la aplicación real.
Y por lo demás, eso es lo que hago, probar, afinar... ¿o es que el precio será muchas veces menor si escribo inmediatamente "no soy de verdad, sino de prueba"?
¿Y el DC? Después de todo, es él quien tiene una orden atascada. ¿Qué sentido tiene entonces enviar un montón de pedidos?
Si no necesita enviar una docena de pedidos a la vez, entonces no insisto.
Puede enviar uno por uno desde un terminal y esperar a que el contexto se libere y así sucesivamente.
Toda la docena puede ser enviada en un par de minutos.
No, bueno, si no necesitas una docena a la vez, entonces no insisto.
Puedes enviar uno a la vez desde un terminal, esperar a que el contexto se libere, y así sucesivamente.
Podrás enviar una docena entera en un par de minutos.
Por eso pregunto, porque no sé cómo se procesan las órdenes en las empresas de corretaje: ¿en paralelo o secuencialmente?
¿en paralelo o secuencialmente?
Las ofertas llegan secuencialmente. pero no es seguro que la compra se ejecute más rápido que la siguiente venta, porque a veces hay otro proveedor de liquidez.
Pero para simplificar el mundo, piensa siempre que va en serie.
la única razón de esta información es permanecer en el tema.