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

[Renat Fatkhullin]

En resumen:

• La suficiencia razonable es encajar en un campo de búsqueda de 2 a la potencia de 64
• Un comportamiento razonable es preestimar el campo de búsqueda en lugar de poner al máximo todas las variables a buscar

Rashid, es poco probable que alguien se atreva a hacer una búsqueda directa. Un optimizador genético de 2^64 lo comprobará fácilmente, pero eso no significa que tengamos que exponer regiones de búsqueda ilimitadas. Al fin y al cabo, tenemos que generar genes para estas regiones y luego manipularlos.

[Sergey Chalyshev]

Rosh:

Bien, hagamos las cuentas. Dejemos que una pasada en el probador tome 1 segundo, entonces dividamos el número de pasadas 2^64-1 por 60 y obtengamos el tiempo de optimización en minutos: 18 446 744 073 709 551 615/60.

A continuación, divide este tiempo entre 8 (8 núcleos en el ordenador) y obtén el tiempo de optimización con este número de pasadas en un ordenador de 8 núcleos. ¿Cuánto se tarda en horas o días?

No cuentes, no estoy hablando de una enumeración directa. Deja que el propio algoritmo genético determine cuántos necesita.

Si lo comparamos con el cerebro humano, según los científicos el cerebro contiene unas 10^10 neuronas y cada una tiene unas 10^4 conexiones sinápticas.

Esto es lo que pretendemos todos, crear programas cada vez más avanzados.

¿Para qué se hizo la computación en nube? Gracias a ello, los usuarios no están limitados a un solo ordenador, por lo que se agradece mucho.

[Sergey Chalyshev]

Renat:

Para abreviar la historia:

• La suficiencia razonable es caber en un campo de búsqueda de 2 a la potencia de 64
• Un comportamiento razonable es preestimar el campo de búsqueda en lugar de poner al máximo todas las variables a buscar

Rashid, es poco probable que alguien se atreva a hacer un sobrepaso directo. Un optimizador genético 2^64 lo comprobará fácilmente, pero eso no significa que tenga que exponer dominios de búsqueda ilimitados. Al fin y al cabo, tenemos que generar genes para estas regiones y luego manipularlos.

Lo que es 2 de cada 64 es un problema muy lejano.

En un algoritmo genético no hay que quedarse con los peores resultados?

¿Qué le impide retorcer al máximo todas las variables?

No puedo entender cuál es la conexión entre los genes y 2^64?

[ddd06]

Sin embargo, puede ser útil para buscar entre muchas variables (por ejemplo, la red neuronal) y esta limitación no es buena.

Así que espera liberarse de las limitaciones))

[Andrey Dik]

El probador de estrategias parece utilizar GA con codificación binaria de cromosomas.

He aquí una cita:

"Sin embargo, la representación binaria de los cromosomas conlleva ciertas dificultades cuando se busca en espacios continuos de gran dimensionalidad, y cuando se requiere una alta precisión se utiliza una técnica especial basada en que todo el intervalo de valores admisibles de una característica [ai,bi] se divide en secciones con la precisión requerida. La precisión requerida p está definida por la expresión

donde N es el número de bits para codificar una cadena de bits.

Esta fórmula muestra que p depende en gran medida de N, es decir, que la precisión de la representación viene determinada por el número de bits utilizados para codificar un cromosoma. Por lo tanto, a medida que N aumenta, el espacio de búsqueda se expande y se vuelve enorme. Un ejemplo de libro muy conocido: si 100 variables varían en el intervalo [-500; 500], hay que encontrar un extremo con una precisión de seis decimales. En este caso, utilizando GA con codificación binaria, la longitud de la cadena será de 3000 elementos y el espacio de búsqueda será de unos¹⁰¹⁰⁰⁰ cromosomas."

Por lo tanto, incluso una red neuronal de tamaño relativamente pequeño en el optimizador estándar, cuando se limita a 64 parámetros a optimizar, no puede ser entrenada. Hay una desventaja más: es muy lento rellenar manualmente los parámetros de las variables optimizables si hay muchas. Por eso ya sugerí que se pueden especificar arrays con parámetros optimizables de forma programática.

Pero hay buenas noticias. Todo lo que falta en el probador y el terminal se puede implementar utilizando los medios nativos de MQL5. Más adelante publicaré los resultados de algunas pruebas de optimización utilizando el probador y el código del programa.

[Andrey Dik]

Sin embargo, nunca esperé los resultados del probador en la tarea de prueba (es decir, esperar es perezoso).

Pero cualquiera puede hacer las pruebas por sí mismo. Para ello puedes tomar el primer ejemplo del artículo. No se olvide de establecer el modo de optimización - búsqueda de máximos (para poder comparar con el optimizador estándar donde sólo se dispone de máximos).

Vamos a escribir un simple Asesor Experto que es aún más simple que un nabo verde y no hace nada más que calcular la función de prueba del usuario:

//+------------------------------------------------------------------+
//|                                                  Test expert.mq5 |
//|                                      Copyright 2010, JQS aka Joo |
//|                              https://www.mql5.com/ru/users/joo |
//+------------------------------------------------------------------+
#property copyright "Copyright 2010, JQS aka Joo"
#property link      "https://www.mql5.com/ru/users/joo"
#property version   "1.00"
//--- input parameters
input double   x1=0.0;
input double   x2=0.0;
//+------------------------------------------------------------------+
//| Expert initialization function                                   |
//+------------------------------------------------------------------+
int OnInit()
  {
//---

//---
   return(0);
  }
//+------------------------------------------------------------------+
//| Expert deinitialization function                                 |
//+------------------------------------------------------------------+
void OnDeinit(const int reason)
  {
//---

  }
//+------------------------------------------------------------------+
//| Expert tick function                                             |
//+------------------------------------------------------------------+
void OnTick()
  {

  }
//+------------------------------------------------------------------+

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)
    );
  }
//+------------------------------------------------------------------+

Los ajustes en la ventana del comprobador son los siguientes:

En la pestaña "Parámetros de entrada", haga lo siguiente:

Y vete.

Las conclusiones aproximadas son las siguientes:

1) El optimizador en el probador es 10-100 veces más lento (a mí me funcionó, aunque la optimización en el probador se realizó en dos núcleos del procesador, mientras que la optimización por software se realizó en un solo núcleo). Lo más probable es que una diferencia tan monstruosa se deba al hecho de que el probador tiene que escribir registros, mostrar información en la pantalla, etc., además de los cálculos directos de FF, es decir, tiene un "frenado forzado" en contraposición a la optimización por software.

2) Es imposible utilizar más de 64 parámetros optimizables en el probador (y en el Asistente para la creación de Asesores Expertos está limitado a 60 parámetros), por lo que es imposible entrenar redes neuronales de un tamaño significativo.

Es o bien escribir sustitutos de prueba por ti mismo (MQL5 lo permite, es una excelente "caña de pescar" pero no un "pez"), o esperar hasta que el algoritmo genético binario del probador sea reemplazado por un algoritmo continuo y la limitación en el número de parámetros optimizados sea eliminada. La segunda no es constructiva, así que la primera permanece. :)

Conclusión global: Aprender MQL5.

PS Una buena solución sería permitir desactivar la salida de información de optimización (registros, gráfico de optimización) y, aún mejor, personalizar los detalles de la información mostrada para aumentar el rendimiento del probador.

[Mr.FreeMan]

joo, hay más cosas, además de escribir un probador y optimizador para cálculos tan no pequeños hay que hacer un distribuidor de cálculos, que implicaría a todos los núcleos del procesador y posiblemente conectar agentes remotos (si se hacen cálculos colectivos). En primer lugar la velocidad del mismo no se puede comparar con el probador estándar - todo se ejecutará mucho más lento, y en segundo lugar para escribir todo esto es necesario gastar mucho tiempo y cientos de kilobytes de código, y todo por lo que, exactamente?

[Mykola Demko]

Mr.FreeMan:
joo, hay más, además de escribir un probador y optimizador para cálculos tan no pequeños, hay que hacer un distribuidor de cálculos, que implicaría a todos los núcleos del procesador y posiblemente conectar agentes remotos (si se hacen cálculos colectivos). En primer lugar, no es comparable con el probador estándar: todo será mucho más lento, y en segundo lugar, para escribir todo esto hay que dedicar mucho tiempo y cientos de kilobytes de código, ¿y cuál es la razón?

El GA de joo ya es más rápido que el estándar, y al portar el código a CPP con studio 10 (adaptado para procesadores multinúcleo) el aumento de velocidad es 6 veces más rápido aún.

[Andrey Dik]

Mr.FreeMan:
joo, hay más cosas; además de escribir un probador y un optimizador para cálculos tan pequeños también hay que hacer un distribuidor para los cálculos que implicarían a todos los núcleos del procesador y posiblemente conectar agentes remotos (si se quieren realizar cálculos colectivos). En primer lugar la velocidad del mismo no se puede comparar con el probador estándar - todo se ejecutará mucho más lento, y en segundo lugar para escribir todo esto se necesita gastar mucho tiempo y cientos de kilobytes de código, y todo por qué, exactamente?

Sobre el rojo respondió Urain .

En cuanto a lo verde, se trata de dinero, por supuesto. El tiempo es dinero. Suelo ser una persona lenta, pero rápida (he tardado más de un año en desarrollar y depurar el AG), y ahora sigo recibiendo mensajes de agradecimiento en mi bandeja de entrada tras la publicación del artículo. :)

No estoy criticando al probador interno. Sólo estoy centrando la atención de los desarrolladores en aquello a lo que hay que prestar especial atención. Al fin y al cabo, por muy bueno que sea el optimizador (el optimizador, no el probador), si es terriblemente lento, todas sus ventajas se desvanecen.

[Andrey Dik]

Justo ahora se me ocurrió un pensamiento audaz. Aunque, de hecho, ¿por qué no habría de hacerlo?

Tendré el honor de utilizar mi UGA en el optimizador de MetaTrader 5 de MetaQuotes Software Corp. Será totalmente gratuito, aunque no rechazaré las bonificaciones, por supuesto.

La UGA es sencilla y eficaz. Muy flexible en los ajustes. En el probador se pueden introducir tres plantillas de ajustes: "Áspero", "Medio" y "Fino", y también mostrar por separado los ajustes con el mensaje "Si no sabes exactamente para qué lo necesitas, no cambies nada en estos ajustes". Entonces será posible llevar a cabo la optimización con el grado deseado de búsqueda de detalles - desde una aproximación muy rápida hasta la búsqueda final exacta de los ajustes óptimos de TC. Por el momento, el optimizador incorporado no permite ser configurado de ninguna manera.