Aquí está la parábola nativa, cuya cima (uno) se buscará a través de GA.
Sin la mezcla de GA no encontré el extremo, pero me acerqué a él
Tester Best result 0.9992924399999999 produced at generation 0. Next generation 1
Tester Best result 0.9992924399999999 produced at generation 0. Next generation 2
Tester Best result 0.9992924399999999 produced at generation 0. Next generation 3
Tester Best result 0.9992924399999999 produced at generation 0. Next generation 4
Tester Best result 0.9992924399999999 produced at generation 0. Next generation 5
Tester Best result 0.999424 produced at generation 5. Next generation 6
Tester Best result 0.99987456 produced at generation 6. Next generation 7
Tester Best result 0.99987456 produced at generation 6. Next generation 8
Tester Best result 0.99987456 produced at generation 6. Next generation 9
Tester Best result 0.99987456 produced at generation 6. Next generation 10
Tester Best result 0.99987456 produced at generation 6. Next generation 11
Tester Best result 0.99987456 produced at generation 6. Next generation 12
Tester Best result 0.99987456 produced at generation 6. Next generation 13
Tester Best result 0.99987456 produced at generation 6. Next generation 14
Tester Best result 0.99987456 produced at generation 6. Next generation 15
Tester Best result 0.99987456 produced at generation 6. Next generation 16
Tester genetic calculation is over
Tester result cache used 973 times
Tester genetic optimization finished on pass 1152 (of 10001)
Statistics optimization done in 0 minutes 00 seconds
Statistics local 179 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%)
Se necesitaron 179 pases. Te recuerdo que el conjunto completo de tareas es de 10001 pases. Sí, el problema es muy simple, pero aún así.
Ahora probemos la variante con barajar (Rand = true).
Tester Best result 0.99949824 produced at generation 0. Next generation 1
Tester Best result 0.99949824 produced at generation 0. Next generation 2
Tester Best result 0.99949824 produced at generation 0. Next generation 3
Tester Best result 0.99949824 produced at generation 0. Next generation 4
Tester Best result 0.99992256 produced at generation 4. Next generation 5
Tester Best result 0.99992256 produced at generation 4. Next generation 6
Tester Best result 0.99992256 produced at generation 4. Next generation 7
Tester Best result 0.99992256 produced at generation 4. Next generation 8
Tester Best result 0.99992256 produced at generation 4. Next generation 9
Tester Best result 0.99992256 produced at generation 4. Next generation 10
Tester Best result 0.99992256 produced at generation 4. Next generation 11
Tester Best result 0.99992256 produced at generation 4. Next generation 12
Tester Best result 0.99992256 produced at generation 4. Next generation 13
Tester Best result 0.99992256 produced at generation 4. Next generation 14
Tester Best result 0.99992256 produced at generation 4. Next generation 15
Tester Best result 0.99992256 produced at generation 4. Next generation 16
Tester genetic calculation is over
Tester result cache used 970 times
Tester genetic optimization finished on pass 1152 (of 10001)
Statistics optimization done in 0 minutes 01 seconds
Statistics local 182 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%)
Otra vez cerca. Se ve claramente en el registro, que 182 pases fueron calculados completamente, y 970 fueron tomados de la memoria caché.
Buen resultado, por lo tanto, vamos a tratar de aumentar el número de puntos en el intervalo.
Este es un buen resultado, así que probemos a aumentar el número de puntos en el intervalo.
El número de puntos del intervalo es de un millón.
Rand = falso
Tester Best result 0.9999999424 produced at generation 3. Next generation 32
Tester genetic calculation is over
Tester result cache used 7533 times
Tester genetic optimization finished on pass 8704 (of 1000001)
Statistics optimization done in 0 minutes 04 seconds
Statistics local 1171 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%)
Rand = true (de un millón de puntos, se intercambiaron pares elegidos al azar 100 millones de veces)
Tester Best result 0.999998294364 produced at generation 10. Next generation 32
Tester genetic calculation is over
Tester result cache used 7452 times
Tester genetic optimization finished on pass 8704 (of 1000001)
Statistics optimization done in 0 minutes 04 seconds
Statistics local 1252 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%)
El resultado muestra que mi afirmación segura de sí misma
Obviamente, si se traza una enumeración completa de y = x^2. A continuación, se barajan aleatoriamente las filas de opimización y se crea un nuevo conjunto basado en el barajado. Entonces el AG no encontrará el vértice de la parábola.
Es más bien falso que verdadero.
Por otra parte, la elección de la función de aptitud como parábola fue inicialmente muy miope, ya que el número de puntos cercanos a uno se sale de lo normal.
Sólo hay una pregunta para el AG, ¿por qué no se encontró el extremo exacto sin mezclar, ya que la función elegida es ideal para esto?
Por otra parte, la elección de una función de aptitud como parábola fue inicialmente muy miope, ya que el número de puntos cercanos a uno se sale de lo normal.
Supongo que si eliges una función con un pico agudo, el GA seguirá rompiendo después de la mezcla. Y dicha función está mucho más cerca de la CT.
He puesto un EA de prueba para el modo matemático del Optimizador
Por desgracia, mis conocimientos no son suficientes para entenderlo todo ))))
Decidí hacerlo más sencillo. En general, he añadido a mi Asesor Experto un registro en el archivo de cadenas legítimas. He encontrado 1953 posibles variantes de 117649. Por cierto, he tardado 3 días en hacer la búsqueda completa en el intervalo de 3 días, sólo precios abiertos y 0 operaciones.
Tester optimization finished, total passes 117649 (successful 114123 passes)
Statistics optimization done in 2 hours 36 minutes 36 seconds
Ahora tengo un archivo. Todavía no sé cómo utilizarlo para la optimización. Lo pensaré mañana...
¿Y por qué hay menos exitosos? ¿Tendremos que volver a hacerlo?
Supongo que si seleccionas una función con un pico agudo, el GA seguirá rompiendo después de la mezcla. Y dicha función está mucho más cerca de la CT.
Así que la genética no está diseñada para captar picos. Su propósito es encontrar regiones estables, que es lo que requiere la CT. Y los picos son ruido, por regla general.
En cuanto a las combinaciones de parámetros incorrectas, deben eliminarse en la fase de formación de la población, es decir, si el intercambio de genes o la mutación dan lugar a un individuo incorrecto, es necesario repetir su generación de nuevo hasta obtener el correcto, entonces todo estará bien.
Si la criba porINIT_PARAMETERS_INCORRECT ocurre después de la formación de la población, reduciendo así el tamaño de esta población, entonces por supuesto esto viola el mecanismo normal de selección genética. Aparentemente MQ tiene esta variante. Y en este caso la tarea del tópico es difícilmente resoluble (en el caso general), bailar con panderetas no ayudará.
Gracias por tu opinión, pero aquí no se discute la arquitectura del programa. En caso de que no te hayas dado cuenta...
Mal, mal.
Estoy de acuerdo en que su problema es exactamente la arquitectura incorrecta del programa. Creo que sólo se puede conseguir el máximo por fuerza bruta, y será muy inestable.
Bueno, pondré otros 5 kopeck. Lo más probable es que se utilicen sobrepasos completos en cada tic. Esto en sí mismo conduce a la lentitud de la operación. Si es así, deberíamos considerar el uso de búsquedas completas sólo en la barra de inicio/abertura del Asesor Experto y luego comprobar los datos más recientes. Esta optimización siempre reduce el consumo de recursos.
La genética no está diseñada para captar picos. Su propósito es encontrar regiones estables, que es lo que requiere la CT. Y los picos son ruido, por regla general.
No es exactamente así. Además, incluso las zonas estables del espacio de optimización siguen siendo zonas con bajadas y picos, el FF está lejos de ser suave.
La genética es una herramienta versátil, se podría ajustar para optimizar un FF corrupto pero en este caso se tardará más en optimizar un FF suave.
En mi opinión, la genética estándar debería digerir conjuntos con la mitad de INIT_PARAMETERS_INCORRECT sin ni siquiera pensarlo. Sobre todo porque estas zonas suelen estar bien agrupadas.
pero en general la mejor solución es transformar el espacio de los parámetros de entrada.
Estoy de acuerdo en que su problema está en la arquitectura incorrecta del programa. Creo que sólo se puede conseguir el máximo por fuerza bruta, y será muy inestable.
No se trata de arquitectura. Se trata del conjunto de funciones y el orden en que se aplican. De hecho, originalmente, estas funciones tenían una única secuencia constante. Entonces decidí que tal vez debería experimentar con el orden de llamada y no llamar a algunos de ellos. Lo he implementado a través de INIT_PARAMETERS_INCORRECT. Puede ver el progreso. Pero tengo un problema con la optimización genética.
Ahora vamos al grano. He creado un archivo con cadenas legítimas. ¿Cómo utilizarlo ahora? Sospecho, que debería usar onTester, marcos... He mirado la documentación, pero algo no cuadra. No se sabe cómo tratarla.
Estoy pensando en leerlo en un array y tomar datos de él...
He hecho un Asesor Experto de prueba para el modo mate del Optimizador
Este es el aspecto de un gráfico de optimización para 8 agentes en paralelo en modo de fuerza bruta completa sin intercalar pases (Rand = false)
Aquí se puede ver claramente que los Agentes están ejecutando tareas por lotes.
Para ver la dependencia del parámetro, pasemos al modo de visualización
Aquí está - una parábola nativa, la parte superior de la cual (unidad) vamos a buscar a través de GA.
En el modo aleatorio (Rand = true), por supuesto, la fuerza bruta completa encuentra nuestro vértice
Aquí está la parábola nativa, cuya cima (uno) se buscará a través de GA.
Sin la mezcla de GA no encontré el extremo, pero me acerqué a él
Se necesitaron 179 pases. Te recuerdo que el conjunto completo de tareas es de 10001 pases. Sí, el problema es muy simple, pero aún así.
Ahora probemos la variante con barajar (Rand = true).
Otra vez cerca. Se ve claramente en el registro, que 182 pases fueron calculados completamente, y 970 fueron tomados de la memoria caché.
Buen resultado, por lo tanto, vamos a tratar de aumentar el número de puntos en el intervalo.
Este es un buen resultado, así que probemos a aumentar el número de puntos en el intervalo.
El número de puntos del intervalo es de un millón.
Rand = falso
Rand = true (de un millón de puntos, se intercambiaron pares elegidos al azar 100 millones de veces)
El resultado muestra que mi afirmación segura de sí misma
Foro sobre trading, sistemas de trading automatizados y pruebas de estrategias de trading
No para los desarrolladores de MT. ¿Por qué sustituir INIT_PARAMETERS_INCORRECT?
fxsaber, 2018.07.10 16:27
Obviamente, si se traza una enumeración completa de y = x^2. A continuación, se barajan aleatoriamente las filas de opimización y se crea un nuevo conjunto basado en el barajado. Entonces el AG no encontrará el vértice de la parábola.
Es más bien falso que verdadero.
Por otra parte, la elección de la función de aptitud como parábola fue inicialmente muy miope, ya que el número de puntos cercanos a uno se sale de lo normal.
Sólo hay una pregunta para el AG, ¿por qué no se encontró el extremo exacto sin mezclar, ya que la función elegida es ideal para esto?
Por otra parte, la elección de una función de aptitud como parábola fue inicialmente muy miope, ya que el número de puntos cercanos a uno se sale de lo normal.
Supongo que si eliges una función con un pico agudo, el GA seguirá rompiendo después de la mezcla. Y dicha función está mucho más cerca de la CT.
He puesto un EA de prueba para el modo matemático del Optimizador
Por desgracia, mis conocimientos no son suficientes para entenderlo todo ))))
Decidí hacerlo más sencillo. En general, he añadido a mi Asesor Experto un registro en el archivo de cadenas legítimas. He encontrado 1953 posibles variantes de 117649. Por cierto, he tardado 3 días en hacer la búsqueda completa en el intervalo de 3 días, sólo precios abiertos y 0 operaciones.
Ahora tengo un archivo. Todavía no sé cómo utilizarlo para la optimización. Lo pensaré mañana...
¿Y por qué hay menos exitosos? ¿Tendremos que volver a hacerlo?Supongo que si seleccionas una función con un pico agudo, el GA seguirá rompiendo después de la mezcla. Y dicha función está mucho más cerca de la CT.
Así que la genética no está diseñada para captar picos. Su propósito es encontrar regiones estables, que es lo que requiere la CT. Y los picos son ruido, por regla general.
En cuanto a las combinaciones de parámetros incorrectas, deben eliminarse en la fase de formación de la población, es decir, si el intercambio de genes o la mutación dan lugar a un individuo incorrecto, es necesario repetir su generación de nuevo hasta obtener el correcto, entonces todo estará bien.
Si la criba porINIT_PARAMETERS_INCORRECT ocurre después de la formación de la población, reduciendo así el tamaño de esta población, entonces por supuesto esto viola el mecanismo normal de selección genética. Aparentemente MQ tiene esta variante. Y en este caso la tarea del tópico es difícilmente resoluble (en el caso general), bailar con panderetas no ayudará.
Gracias por tu opinión, pero aquí no se discute la arquitectura del programa. En caso de que no te hayas dado cuenta...
Mal, mal.
Estoy de acuerdo en que su problema es exactamente la arquitectura incorrecta del programa. Creo que sólo se puede conseguir el máximo por fuerza bruta, y será muy inestable.
Lo más probable es que se utilicen sobrepasos completos en cada tic. Esto en sí mismo conduce a la lentitud de la operación. Si es así, deberíamos considerar el uso de búsquedas completas sólo en la barra de inicio/abertura del Asesor Experto y luego comprobar los datos más recientes. Esta optimización siempre reduce el consumo de recursos.
La genética no está diseñada para captar picos. Su propósito es encontrar regiones estables, que es lo que requiere la CT. Y los picos son ruido, por regla general.
No es exactamente así. Además, incluso las zonas estables del espacio de optimización siguen siendo zonas con bajadas y picos, el FF está lejos de ser suave.
La genética es una herramienta versátil, se podría ajustar para optimizar un FF corrupto pero en este caso se tardará más en optimizar un FF suave.
En mi opinión, la genética estándar debería digerir conjuntos con la mitad de INIT_PARAMETERS_INCORRECT sin ni siquiera pensarlo. Sobre todo porque estas zonas suelen estar bien agrupadas.
pero en general la mejor solución es transformar el espacio de los parámetros de entrada.
En vano, en vano.
Estoy de acuerdo en que su problema está en la arquitectura incorrecta del programa. Creo que sólo se puede conseguir el máximo por fuerza bruta, y será muy inestable.
No se trata de arquitectura. Se trata del conjunto de funciones y el orden en que se aplican. De hecho, originalmente, estas funciones tenían una única secuencia constante. Entonces decidí que tal vez debería experimentar con el orden de llamada y no llamar a algunos de ellos. Lo he implementado a través de INIT_PARAMETERS_INCORRECT. Puede ver el progreso. Pero tengo un problema con la optimización genética.
Ahora vamos al grano. He creado un archivo con cadenas legítimas. ¿Cómo utilizarlo ahora? Sospecho, que debería usar onTester, marcos... He mirado la documentación, pero algo no cuadra. No se sabe cómo tratarla.
Estoy pensando en leerlo en un array y tomar datos de él...