Discusión sobre el artículo "Optimización móvil continua (Parte 7): Encajando la parte lógica del optimizador automático con la parte gráfica y el control de la misma desde el programa"
Has vuelto a demostrar tu alto nivel profesional como programador. Un poco más de usabilidad, por así decirlo, para conseguir más popularidad. Para entender estos artículos se necesita una cantidad de tiempo proporcional dedicado a escribirlos. ¿Pondrías tu optimizador en kodobase, sólo como código e instrucciones de uso? Tal vez lo vean más operadores.
Veo que aún no ha aparecido el criterio de optimización personalizado y la altura en el calendario..... Dado que OnTester() se utiliza obligatoriamente, podríamos hacer con sólo el criterio personalizado en absoluto. Y una vez más quiero reflexionar sobre la automatización de la introducción de los periodos de prueba. Mi práctica muestra que es mejor realizar la optimización de la prueba hacia adelante en períodos de 3-5 semanas en varios instrumentos. Escribir manualmente todos los periodos para cada pieza no es apto para pusilánimes. No es difícil crear un script utilizando las herramientas MQL5 para recibir y dar salida a los periodos, pero debido a las limitaciones de sandbox y de formato, tendrá que transferirlos manualmente al Auto-Optimizador. Puede hacerlo en la funcionalidad del programa. Puede que no lo necesite personalmente, pero ¿para quién ha escrito artículos tan grandes y complejos?
Un funcionamiento fiable es la ventaja de tu Auto-Optimizador frente a su conocido análogo, mientras que la complejidad de su configuración es una desventaja. Pero tienes un manual para quien lo encuentre.
Has vuelto a demostrar tu alto nivel profesional como programador. Un poco más de usabilidad, por así decirlo, para conseguir más popularidad. Para entender estos artículos se necesita una cantidad de tiempo proporcional dedicado a escribirlos. ¿Pondrías tu optimizador en kodobase, sólo como código e instrucciones de uso? Quizá lo vean más operadores.
El criterio de optimización personalizado, veo, no ha aparecido todavía y la altura en el calendario..... Dado que OnTester() se utiliza obligatoriamente, podríamos hacer con sólo el criterio personalizado en absoluto. Y una vez más quiero reflexionar sobre la automatización de la introducción de los periodos de prueba. Mi práctica muestra que es mejor realizar la optimización de la prueba hacia adelante en períodos de 3-5 semanas en varios instrumentos. Escribir manualmente todos los periodos para cada pieza no es apto para pusilánimes. No es difícil crear un script utilizando las herramientas MQL5 para recibir y dar salida a los periodos, pero debido a las limitaciones de sandbox y de formato, tendrá que transferirlos manualmente al Auto-Optimizador. Puede hacerlo en la funcionalidad del programa. Puede que no lo necesites personalmente, pero ¿para quién has estado escribiendo artículos tan grandes y complejos?
El funcionamiento fiable es la ventaja de tu Auto-Optimizador sobre su conocido análogo, mientras que la complejidad de su configuración es una desventaja. Pero tienes un manual para quien lo encuentre.
Gracias por su comentario. Como he escrito en la conclusión del artículo, voy a añadir todas las adiciones en el último artículo. Este es uno de los previstos anteriormente. Traté de describir en todos los artículos que se publican - todo el programa de la parte que carga los informes a la estructura interna del propio auto optimizador. Me acuerdo de las ediciones prometidas y ya estoy trabajando en ellas. Sin embargo, las publicaré en el próximo artículo, ya que primero tenía que completar la descripción de la primera versión del programa. Como recuerdo que nos decía un profesor en la universidad: "Una empresa fabricante de coches no cambiará el sistema de frenos por uno nuevo en la versión ya producida de los coches".
En cuanto al código, está adjunto al artículo y puedes cambiarlo, desmontarlo y modernizarlo si lo necesitas (haré las ediciones prometidas, y si necesitas algo más individual, puedes añadirlo como variante o simplemente trabajarlo si te interesa), por eso lo escribo con tanto detalle que habría una imagen de cómo funciona todo. Añadiré la división automática de periodos.
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Usted acepta la política del sitio web y las condiciones de uso
Artículo publicado Optimización móvil continua (Parte 7): Encajando la parte lógica del optimizador automático con la parte gráfica y el control de la misma desde el programa:
Este artículo es el penúltimo de la serie, y describe cómo encajar la parte gráfica del programa del optimizador automático con su parte lógica. En él, analizaremos el proceso de inicio y optimización, comenzando por la pulsación del botón y terminando el redireccionamiento al gestor de optimizaciones.
Como hemos dicho más de una vez, ViewModel es la capa encargada de encajar la parte gráfica de la aplicación y la implementación programática de la lógica. En esencia, es una representación programática de la parte gráfica, donde se implementan la invoación de la lógica y la reacción de la parte gráfica a las llamadas de retorno por parte de la lógica de la aplicación. Por consiguiente, a cada campo modificado de la parte gráfica de la aplicación le corresponde una propiedad pública de una parte de ViewModel. Estas propiedades pueden ser tanto getters (lo cual excluye la posibilidad de modificar estas desde el gráfico), como setters (lo cual permite registrar nuevamente el objeto que se oculta tras esta propiedad). Ya hemos analizado detalladamente en los anteriores artículos la tecnología encargada de conectar los datos, por ello, aquí solo mostraremos un par de ejemplos.
La conexión de los campos de texto se realiza con la ayuda de las propiedades con acceso, tanto para el registro, como para la lectura de datos. Analizaremos como ejemplo el campo en el que se indica el nombre del activo con el que se realizará la optimización. El marcado XAML de este campo es muy sencillo.
Aparte de la indicación de la anchura de la ventana, podemos ver los campos IsEnabled y Text. El primero de ellos se encarga de la accesibilidad del campo para la edición. Si este se ha establecido en true, el campo estará disponible para la edición, si ha establecido en false, estará bloqueado. La propiedad Text contiene el propio texto introducido en este campo. A continuación, frente a cada uno de ellos, vemos una construcción entre llaves. Todo lo que se encuentra en ella, implementa la conexión del objeto con una propiedad pública determinada de la clase ViewModel, indicada tras el parámetro "Binding".
Autor: Andrey Azatskiy