![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
Podrías tener un intervalo más largo. Al menos 30 segundos para la prueba.
Con la normalización.
Sin normalización.
El mismo 20%.
Así es como trabaja un Agente, cuenta constantemente lo mismo. Si se elimina toda la aleatoriedad, el rendimiento neto se acerca al más corto.
Net no es interesante, ya que no es realizable en la realidad.
Gracias por las pruebas.
Con la normalización.
Sin normalización.
El mismo 20%.
20% para un EA ficticio que no hace nada... No es muy significativo. En el código real, la cifra sería muchas veces menor. ¿Merece la pena perder el tiempo en estas trivialidades?
Y hablando de optimizar los cálculos, deberíamos empezar por el hecho de que no es necesario controlar constantemente los niveles de todas las órdenes pendientes. Sólo tenemos que comprobar el más cercano. Si se alcanza, entonces el siguiente nivel y así sucesivamente.
20% para un EA ficticio que no hace nada... No es muy significativo. En el código real la cifra sería muchas veces menor. ¿Merece la pena perder el tiempo en estas trivialidades?
La observación es justa. En mi robot normal veo demasiado retraso en el Tester. Hay muchas razones para ello. Y ésta es una de ellas. Una pasada son 100 millones de ticks. Tomemos la genética estándar para los pases de 10K. Eso es un trillón de ticks por lo menos. En cada tic el probador hace al menos una normalización. Cuando no podía hacer nada. ¿Cuál es el ahorro de esta optimización? Además, molestarse es hacer una normalización en cada comparación, como ocurre ahora. En realidad, es más fácil y eficaz normalizar sólo los precios de entrada.
Y hablando de la optimización de los cálculos, hay que empezar por el hecho de que no es necesario controlar constantemente los niveles de todas las órdenes pendientes. Sólo tenemos que comprobar el más cercano. Si se alcanza, se comprueba el siguiente nivel, etc.
El comprobador incorporado se retrasa mucho cuando aumenta el número de pedidos. Los TS de la red son sus "asesinos". He sugerido esa optimización algorítmica. No creo que la emprendan.
Aquí no estamos hablando de una gran cantidad de cálculos internos que acompañan a cada tic del probador.