Discusión sobre el artículo "Algoritmos de optimización de la población: Algoritmo de recocido simulado (Simulated Annealing, SA). Parte I" - página 2
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
Exactamente.
Es una tecnología extremadamente incómoda tanto para la codificación como para su uso posterior en la práctica. Así lo confirma, por ejemplo, el hecho de que el optimizador interno no la utilice.
Este enfoque apenas puede aplicarse cuando hay que realizar múltiples optimizaciones (un número indefinido de veces y posiblemente con un conjunto indefinido de parámetros en cada ocasión). Por ejemplo, podría tratarse de modelos MO ensemble.
Qué se puede decir aquí... OpenCL no es tan terrible ni conveniente, el código en él sintácticamente no difiere de MQL5 (a menos que uses funciones específicas de MQL5). Usted puede paralelizar no sólo secciones de código lógico separadas, sino también, por ejemplo, toda la lógica de un Asesor Experto en OpenCL, organizando ejecuciones a través de la historia a la manera de un optimizador estándar en agentes. Así, es posible organizar la optimización/formación en el modo en línea del Asesor Experto.
MetaQuotes ha proporcionado capacidades de paralelización, pero si las características del lenguaje nativo llegaran a estar disponibles, sería genial. Creo que es más fácil para los desarrolladores implementar trites de funciones (es más rápido esperar a los usuarios) que la paralelización automática de secciones de código. Como deseo de los desarrolladores, espero que sea escuchado.
Que se puede decir aqui... OpenCL no es tan terrible y no conveniente, el código en él sintácticamente no difiere de MQL5 (a menos que utilice funciones específicas de MQL5). Usted puede paralelizar no sólo las secciones de código lógico separadas, sino también, por ejemplo, toda la lógica de un Asesor Experto en OpenCL, organizando las ejecuciones a través de la historia a la manera de un optimizador estándar en los agentes. Así es como se puede organizar la optimización/formación en el modo online del Asesor Experto.
.
MetaQuotes ha proporcionado características de paralelización, pero si hay características de lenguaje nativo, sería genial. Creo que es más fácil para los desarrolladores implementar trites de funciones (es más rápido esperar a los usuarios) que la paralelización automática de fragmentos de código. Como deseo de los desarrolladores, espero que sea escuchado.
Imho, las posibilidades son muy pobres.
Ha surgido una pregunta sobre el recocido poblacional. ¿Tendría sentido que cada solución de la población eligiera sus parámetros de recocido (aleatoriamente dentro de unos límites razonables)? ¿Podría esto a) mejorar la convergencia y b) ser un análogo de la selección de metaparámetros óptimos?
El problema no está tanto en la codificación en sí, aunque probablemente lo habrá debido a la falta de manuales. Por lo que sé, hay problemas al portar programas a GPUs distintas de aquella en la que fueron depurados. De nuevo no estoy seguro de si esto se llevará a cabo cuando MT5 se ejecute en linux a través de wyne. La solución encontrada a los problemas siempre puede romperse debido a actualizaciones inesperadas de MT, etc.
OpenCL se desarrolló precisamente como una forma universal de organizar cálculos paralelos en dispositivos multinúcleo (no importa si GPU o CPU). La probabilidad de problemas de los programas OpenCL en diferentes dispositivos no es mayor (y puede ser incluso menor) que la de las aplicaciones Windows normales en ordenadores con diferente hardware.
No sé cómo están las cosas con vyne, siempre ha habido problemas con él, depende de las especificidades y la calidad de la virtualización del entorno Windows.
Ha surgido una pregunta sobre el recocido poblacional. ¿Tendría sentido que cada solución de la población eligiera sus parámetros de recocido (aleatoriamente dentro de unos límites razonables)? ¿Podría esto a) mejorar la convergencia y b) ser un análogo de la selección de metaparámetros óptimos?
Buena pregunta. Cuando pruebo algoritmos y selecciono sus parámetros externos, parto del rendimiento global agregado en un conjunto de funciones de prueba, aunque en cada una de ellas los mejores parámetros pueden ser diferentes (y suelen serlo). Además, diferentes parámetros externos también pueden ser los mejores para diferentes dimensiones del problema. Por lo tanto
a) mejorará la precisión de la convergencia en distintos tipos de problemas y reducirá la probabilidad de atascarse.
b) sí
Lo único es que es probable que esta técnica reduzca un poco (o mucho, habría que ver) la velocidad de convergencia (al tiempo que aumenta la precisión de la convergencia).
Buena pregunta. Cuando pruebo algoritmos y selecciono parámetros externos de algoritmos, procedo a partir del rendimiento global agregado en un conjunto de funciones de prueba, aunque los mejores parámetros pueden ser diferentes para cada función individual (y normalmente lo son, diferentes). Además, diferentes parámetros externos también pueden ser los mejores para diferentes dimensiones del problema. Por lo tanto, sí:
(a) mejorará la precisión de la convergencia en diferentes tipos de problemas y reducirá la probabilidad de atascarse.
b) sí
Lo único es que es probable que esta técnica reduzca un poco (o mucho, hay que ver) la velocidad de convergencia (al tiempo que aumenta la precisión de la convergencia).