Optimización en el Probador de Estrategias - página 8
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
Ahora, la ejecución de la prueba en el ejemplo anterior tiene una sobrecarga del sistema de alrededor de 1,5 segundos al inicio para preparar todos los datos (autorización y sincronización de los datos de cálculo). La cuestión es que los agentes de prueba son completamente independientes y están desacoplados del terminal, lo que lleva a la necesidad de transferir y sincronizar completamente todos los datos utilizados.
No podemos decir que el optimizador o probador genético sea lento en los cálculos superrápidos de varios segundos, ya que la sobrecarga del sistema tiene una gran influencia en el tiempo de cálculo final. En cálculos largos de 20 segundos o más por ejecución, el impacto de la sobrecarga del sistema se reduce a valores insignificantes.
Con cada compilación reducimos este tiempo almacenando en caché la mayor parte de los datos directamente en los agentes. Creo que pronto resolveremos este asunto.
El GA de joo ya es más rápido que el estándar, y cuando el código se transfiere a CPP mediante Studio 10 (adaptado a CPUs multinúcleo) la aceleración es otras 6 veces más rápida.
Es sin entorno de mercado que se puede organizar una calculadora de velocidad personalizada para una tarea específica.
Pero cuando se trata de hacer un motor de comercio universal con el suministro a la carta de cualquier dato poti multidivisa con el cálculo automático de los beneficios/límites y los informes, la velocidad caerá inmediatamente en 2-3-4 órdenes de magnitud.
Ahora, la ejecución de pruebas en el ejemplo anterior tiene una sobrecarga del sistema de aproximadamente 1,5 segundos al inicio para preparar todos los datos (autorización y sincronización de los datos de cálculo). La cuestión es que los agentes de prueba son completamente independientes y están desacoplados del terminal, lo que lleva a la necesidad de transferir y sincronizar completamente todos los datos utilizados.
No podemos decir que el optimizador o probador genético sea lento en los cálculos superrápidos de varios segundos, ya que la sobrecarga del sistema tiene una gran influencia en el tiempo de cálculo final. En cálculos largos de 20 segundos o más por ejecución, el impacto de la sobrecarga del sistema se reduce a valores insignificantes.
Con cada compilación reducimos este tiempo almacenando en caché la mayor parte de los datos directamente en los agentes. Creo que pronto resolveremos este asunto.
Sin un entorno de mercado, es posible establecer un contador rápido personalizado para una tarea específica.
Pero cuando se trata de hacer un motor de negociación universal con suministro a la carta de cualquier dato multidivisa con cálculo automático de beneficios/límite e informes, la velocidad caerá inmediatamente en 2-3-4 órdenes de magnitud.
Renat, no me refiero a que se necesite tiempo para preparar el entorno del mercado y otros "frenos" inevitables, escribí en la página anterior:
Lo más probable es que una diferencia tan monstruosa se debe al hecho de que el probador, además de los cálculos directos FF, la necesidad de escribir los registros, la información de la pantalla, etc, que está presente "frenado forzado"
2010.11.28 17:38:30 Núcleo 1 pase genético (424, 98130899813578) devuelve el resultado 48,16 en 2059 ms
2010.11.28 17:38:30 Paso genético del núcleo 2 (426, 990006720) iniciado
2010.11.28 17:38:30 core 2 genetic pass (425, 56291461) devuelve el resultado 26.67 en 2012 ms
2010.11.28 17:38:28 core 2 genetic pass (425, 56291461) iniciado
2010.11.28 17:38:28 core 2 genetic pass (423, 1510001908) devuelve el resultado 49.98 en 2028 ms
2010.11.28 17:38:28 core 1 genetic pass (424, 98130899813578) iniciado
2010.11.28 17:38:28 core 1 genetic pass (422, 1668020166802) devuelve el resultado 48.36 en 2013 ms
2010.11.28 17:38:26 core 2 genetic pass (423, 1510001908) iniciado
2010.11.28 17:38:26 core 2 genetic pass (419, 99260769921339) devuelve el resultado 49.22 en 1935 ms
2010.11.28 17:38:26 core 1 genetic pass (422, 1668020166802) iniciado
2010.11.28 17:38:26 core 1 genetic pass (418, 32073563420604) devuelve el resultado 26.13 en 1934 ms
2010.11.28 17:38:24 Se ha encontrado en la caché un pase genético del probador (421, 730000073) con el resultado 50.00
2010.11.28 17:38:24 Se ha encontrado en la caché un pase genético del probador (420, 2080000208) con el resultado 50.00
2010.11.28 17:38:24 Paso genético del núcleo 2 (419, 99260769921339) iniciado
2010.11.28 17:38:24 2010/11/28 17:38:24 Core 2 genetic pass (417, 99249619924961) devuelve el resultado 49.26 en 2059 ms
2010.11.28 17:38:24 core 1 genetic pass (418, 32073563420604) iniciado
2010.11.28 17:38:24 core 1 genetic pass (416, 2479846771) devuelve el resultado 48.49 en 2309 ms
2010.11.28 17:38:22 core 2 genetic pass (417, 99249619924961) iniciado
Es decir, se tarda más de 2 segundos en calcular la FF desnuda, y eso mientras no hay ninguna referencia al entorno del mercado.
El optimizador resuelve una tarea tan sencilla como f(x1,x2)=x1*x1+x2*x2 en algún momento de la 500ª "pasada" y sigue probando variantes ya que ha definido más de 1000 variantes a calcular.
Y no hay ajustes que afecten a la capacidad de búsqueda del algoritmo, además, el límite de 64 parámetros optimizables es frustrante.
Es posible configurar un calculador de velocidad personalizado para una tarea específica sin un entorno de mercado.
Pero cuando se trata de hacer un motor de comercio universal con provisión de cualquier dato multidivisa bajo demanda con cálculo automático de beneficios/límites e informes, la velocidad caerá inmediatamente en 2-3-4 órdenes de magnitud.
No voy a discutir, pero sería bueno ampliar los parámetros de control del algoritmo, la misma configuración de salida de búsqueda y el número de parámetros de búsqueda.
Aquí en mql5 estamos trabajando en algoritmos para buscar 3000 parámetros, y no es el límite, por supuesto no en codificación binaria sino en el plano continuo.
Y todavía tienes un SRR en tus manos.
He intentado hacerlo en codificación binaria, pero GA pierde en tal caso en mql5. La búsqueda continua es buena porque ella misma reduce el paso a la convergencia. Además, no necesitamos recursos para la codificación/descodificación. Bueno, en general necesitamos pruebas correctas, es demasiado pronto para decir algo con seguridad.
El optimizador genético será probablemente más personalizable + minimizaremos la sobrecarga del sistema.
Muchas gracias. Esto es realmente muy importante, más importante de lo que muchos podrían pensar.
Y esperemos que también nos olvidemos de "Umbral 64" en algún momento.
En la nueva compilación 366 (que sale el lunes) hemos reducido la sobrecarga del sistema a valores mínimos.
El experto en genética de arriba pasa ahora entre 200 y 300 ms en lugar de 2 segundos por pase.
Muchas gracias. Realmente es muy importante, más de lo que muchos podrían pensar.
Y esperemos que también nos olvidemos de Umbral 64 en algún momento.
Olvídalo ahora mismo, a 4 parámetros a 8 dígitos el comprobador da un aviso de que la sobremedida ha superado la longitud larga.
Por lo tanto, para otras necesidades que no sean las de probar EAs, escriba un optimizador personalizado.
Y 64 parámetros son suficientes para optimizar los EAs.
Sí, he leído el hilo, de dónde sacan asesores con tantos parámetros:)
Sí, he leído el hilo, de dónde sacan asesores con tantos parámetros:)