Optimización en el Probador de Estrategias - página 10

Nuevo comentario
 

En las últimas versiones hemos eliminado por completo los gastos generales del sistema en las ejecuciones de tareas, reduciéndolos de casi 2000 ms a cero.

Aquí están los resultados de la ejecución de una tarea de cálculo, que fue sugerida por joo:

input double   x1=0.0;
input double   x2=0.0;
double OnTester()
  {
   return
   (
    pow(cos((double)(2*x1*x1))-0.11 e1,0.2 e1)+
    pow(sin(0.5 e0 *(double) x1)-0.12 e1,0.2 e1) -
    pow(cos((double)(2*x2*x2))-0.11 e1,0.2 e1)+
    pow(sin(0.5 e0 *(double) x2)-0.12 e1,0.2 e1)
    );
  }

Ajustes (las fechas están puestas a propósito para que no se utilice el historial del gráfico):

Parámetros a ejecutar:

Agentes utilizados (4 agentes locales):

Resultados de la optimización:

La optimización duró sólo 25 segundos y se realizaron 18.432 pases:



Resultado global: MetaTrader 5 y su red de agentes pueden utilizarse para realizar cálculos matemáticos masivos.

 
Renat:

En las últimas versiones, hemos eliminado por completo los gastos generales del sistema en las ejecuciones de tareas, reduciéndolos de casi 2000 ms a cero.

Aquí están los resultados de la ejecución de una tarea de cálculo, que fue sugerida por joo:

Ajustes (las fechas están puestas a propósito para que no se utilice el historial del gráfico):

Parámetros a ejecutar:

Agentes en uso (4 agentes locales):

Resultados de la optimización:

La optimización duró sólo 25 segundos y se realizaron 18.432 pases:

El resultado global: MetaTrader 5 y su red de agentes pueden utilizarse para realizar cálculos matemáticos masivos.

Este es un resultado muy bueno. Ahora el optimizador es realmente más o menos adecuado para las tareas de optimización (tanto las relacionadas con el comercio como las no relacionadas con el comercio). Los resultados serán aún mejores si el número de pasadas se reduce a 2-3 miles para esta tarea específica con la configuración predeterminada del optimizador GA, pero para ello es necesario mostrar la configuración GA para el acceso del usuario (será posible reducir el número de pasadas a 500-900 si el usuario quiere).

Queda un problema relacionado con la limitación del espacio de búsqueda. Se ha hecho una propuesta de optimizador correspondiente en servicedesk.

 
joo:

Este es un resultado muy bueno. Ahora el optimizador es realmente más o menos adecuado para las tareas de optimización (tanto las relacionadas con el comercio como las no relacionadas directamente con el comercio). Los resultados serían aún mejores si el número de pasadas se redujera a 2.000 o 3.000 para esta tarea específica con la configuración predeterminada del optimizador, pero para ello es necesario poner a disposición del usuario la configuración del AG (será posible reducir el número de pasadas a 500-900 si el usuario lo desea).

Queda un problema relacionado con la limitación del espacio de búsqueda. Se ha hecho la correspondiente propuesta de optimizador en el servicio de atención al cliente.

Y la solución a este problema está relacionada principalmente con este problema:

Si el desbordamiento del pase de optimización ya ocurre en 4 parámetros, entonces hablar de aumentar el número de parámetros más de lo permitido ahora (64) no es apropiado todavía.

 
Urain:

Y la solución a este problema está ligada principalmente a este problema:

Si el desbordamiento de la optimización ya ocurre en 4 parámetros, entonces hablar de aumentar el número de parámetros más de lo permitido ahora (64) no es apropiado todavía.

Por supuesto. Aproximadamente, el espacio de búsqueda es P=n*paso, donde n-número de parámetros a optimizar y paso-paso del parámetro. Al mismo tiempo, P debe ser menor que Pmax (espacio de búsqueda máximo posible, limitado por las características de la codificación binaria del cromosoma). Por lo tanto, una de las restricciones introducidas artificialmente (por ejemplo, usted puede hacer un límite de 10000 parámetros, pero entonces el paso será más de lo necesario para resolver la mayoría de los problemas de optimización), para que P no exceda Pmax, se introdujo una restricción en n.

Las opiniones al respecto se expresan en la propuesta de optimizador en servicedesk.


PS Con el crecimiento de las redes de agentes remotos, el problema del elevado número de ejecuciones está desapareciendo. Pero, por supuesto, sólo si se eliminan las restricciones de la codificación binaria de los cromosomas (léase: cambiar a la codificación de los cromosomas con números reales).

 
joo:

Por supuesto. A grandes rasgos, el espacio de búsqueda es P=n*paso, donde n-número de parámetros a optimizar y paso-paso del parámetro. Así, P debe ser menor que Pmax (espacio de búsqueda máximo posible, limitado por las características de la codificación binaria del cromosoma). Por lo tanto, una de las restricciones, introducidas artificialmente (por ejemplo, se puede hacer un límite de 10000 parámetros, pero entonces el paso será más de lo necesario para resolver la mayoría de los problemas de optimización), que P no iría más allá de Pmax, se introdujo la limitación en n.

En la propuesta del optimizador en el Servicio de Atención al Cliente se dan ideas al respecto.


PS A medida que crecen las redes de agentes remotos, desaparece el problema del gran número de ejecuciones. Pero, por supuesto, sólo si se eliminan las restricciones de la codificación binaria de los cromosomas (léase: cambiar a la codificación de los cromosomas con números reales).

Ligeramente equivocado, el número correcto de variantes es P=paso_0*paso_1*...*paso_n

que, si el tamaño del paso es igual, resulta en P=paso^n

 
Urain:

Ligeramente equivocado, el número correcto de opciones es P=paso_0*paso_1*...*paso_n

que, si el tamaño del paso es igual, resulta en P=paso^n

Pues sí, tienes razón, sólo digo -a grandes rasgos, para ser más claro y evidente- que depende de qué.
 
Renat:

En las últimas versiones, hemos eliminado por completo los gastos generales del sistema en el inicio de las tareas, reduciéndolos de casi 2000 ms a cero.

¡Fantástico! Oh, cuánto tiempo perdido durante el verano en la optimización...

Lo primero es lo primero. Realicé la prueba de joo en la compilación actual y en la compilación 319 (02 Sep 2010). resultados:

2010 12/229 15:49:18 El probador pasó en 2 minutos y 41 segundos
2010.12.29 15:49:18 La optimización del probador ha terminado en la pasada 15360 (de 100000020000001)
2010.12.29 15:49:18 La caché de resultados de la prueba se ha utilizado 7265 veces
2010.12.29 15:49:13 La genética de los probadores ha terminado
2010.12.29 17:10:59 La optimización de la prueba se ha realizado en 1 hora, 17 minutos y 34 segundos
2010.12.29 17:10:59 La optimización genética del probador ha terminado en la pasada 18176 (de 100000020000001)
2010.12.29 17:10:59 La caché de resultados de la prueba se ha utilizado 10582 veces
2010.12.29 17:10:52 La genética de los probadores ha terminado

No sé si felicitar o agradecer. Gracias.

 
Urain:

Y la solución a este problema tiene que ver con este problema en primer lugar:

Si el desbordamiento de los pases de optimización se produce ya en 4 parámetros, entonces hablar de aumentar el número de parámetros más de lo permitido ahora (64) no es apropiado todavía.

Utilice un enfoque razonable para la búsqueda, pero no gire los mandos al máximo en el modo "los hombres rusos rompen la motosierra japonesa".

En cuanto empiece a aplicar la optimización genética en el trabajo real, empezará inmediatamente a elegir límites razonables.

 
Yedelkin:

¡Fantástico! Eh, cuánto tiempo se perdió durante el verano en la optimización...

En orden. Lo he probado en la build actual y en la 319 (02 Sep 2010):

2010.12.29 15:49:18 La optimización del probador pasó en 2 minutos y 41 segundos
2010.12.29 15:49:18 La optimización genética del probador terminó en la pasada 15360 (de 100000020000001)
2010.12.29 15:49:18 La caché de resultados del probador se utilizó 7265 veces
2010.12.29 15:49:13 La genética del probador ha terminado
2010.12.29 17:10:59 La optimización del probador pasó en 1 horas 17 minutos 34 segundos
2010.12.29 17:10:59 La genética del probador terminó en la pasada 18176 (de 100000020000001)
2010.12.29 17:10:59 La caché de resultados del probador se utilizó 10582 veces
2010.12.29 17:10:52 La genética del probador ha terminado

No sé si felicitar o agradecer. Gracias.

Obsérvese que hemos reducido la sobrecarga del sistema en las fases de "sincronización/transmisión de datos iniciales del terminal al agente y recepción de resultados del agente", lo que ha permitido ahorrar entre 1,5 y 2 segundos por ejecución. No hubo aceleración de los cálculos en la propia lengua.

Es decir, el efecto más grave que tiene esto es en los cálculos de alta velocidad, en los que el cálculo tarda un tiempo cercano a cero. Para los cálculos masivos el ahorro no es tan pronunciado. Aunque un ahorro de 2 segundos por cada 10.000 pasadas da 20.000 s = 333 minutos = 5,5 horas.

 
Renat:
No es así.

He notado que tiene un efecto. Corrí el EA en días laborables y lo corrí con spread extendido ahora, el resultado es bastante diferente, el spread es de unos 4 pips (cuatro dígitos) en Eurobuck ahora. Así que hay un poco de atasco de propagación en el fin de semana en mt5 también, así que no quiero correr en el fin de semana, porque la optimización no será correcta. Incluso puedo verlo visualmente en mt4 donde un EA se ha estado optimizando desde el lunes y la curva de resultados ha bajado desde el fin de semana; esto demuestra que el spread afecta a los resultados de optimización, se han vuelto peores.

1...34567891011121314151617...19
Nuevo comentario