Métodos para llevar a cabo una renovación - página 5
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
Sí, deberíamos haber creado un tema hace mucho tiempo: cómo debería ser un delantero lobo en MT. Simplemente no puedo hacerlo. Por cierto, hace poco hubo algo sobre este tema en la parte de futuros del foro.
Algunas personas se resisten a contarte lo que necesitan, pues creen que al hablarte del método te darán algo más valioso que el propio experto. Y en cierto modo tienen razón. Yo, por ejemplo, les hablé de mi método. Quizás porque lo considero imperfecto y quiero mejorarlo. Por cierto, su método tampoco es muy claro. ¿Podría decirnos qué se hace paso a paso y qué hace su optimizador automático?
No puede haber métodos especiales de volking-forwarding. Es unprincipio perfectamente claro de comprobaciónpaso a paso y el propio EA es, por supuesto, primordial para el resultado. Y el principio de comprobación se cumple o no. Así que, o es un volking forward o no lo es. Por lo tanto, mi método es absolutamente clásico. Nada nuevo. (Tengo algo nuevo en mente, pero no he llegado a ponerlo en práctica).
Optimizar hacia atrás - obtener el avance de la parte no optimizada y evaluarla - avanzar por la longitud del avance - optimizar de nuevo con los ajustes anteriores - etc.
Lo que has contado sobre los conjuntos acumulados y la ejecución general con ellos no es más que una variante de la evaluación de los forwards (suponiendo que para obtenerlos hayas cargado el conjunto obtenido para el periodo anterior en cada paso de la optimización). Si es más conveniente para usted, está bien. Lo principal que salvó el principio.
No puede haber métodos especiales de volking-forwarding. Es unprincipio perfectamente claro de comprobaciónpaso a paso y el propio EA es, por supuesto, primordial para el resultado. Y el principio de comprobación se cumple o no. Así que, o es un volking forward o no lo es. Por lo tanto, mi método es absolutamente clásico. No hay nada nuevo aquí.
Optimizamos hacia atrás - obtenemos el avance de la parte no optimizada y lo evaluamos - avanzamos por la longitud del avance - optimizamos de nuevo con los ajustes anteriores - etc.
Lo que has contado sobre los conjuntos acumulados y la ejecución general con ellos no es más que una variante de la evaluación de los forwards (suponiendo que para obtenerlos hayas cargado el conjunto obtenido para el periodo anterior en cada paso de la optimización). Si es más conveniente para usted, está bien. Lo principal es que se mantenga el principio.
La metodología es la misma, estoy de acuerdo.
¿Y qué pasa con la selección de un único resultado entre más de 10.000 opciones de la prueba retrospectiva? ¿Por el máximo beneficio? O por beneficio máximo con algún nivel de drawdown (lo elijo con drawdown < 20%). ¿O otro método de selección?
El criterio de selección del resultado: ¿uno para todos los sectores? (Creo que debería ser) ¿O diferente?
La metodología es la misma, estoy de acuerdo.
¿Y qué hay de elegir el único resultado de entre más de 10.000 opciones de la prueba de espalda? ¿Por el máximo beneficio? O por beneficio máximo con algún nivel de drawdown (lo elijo con drawdown < 20%). ¿O otro método de selección?
El criterio de selección del resultado: ¿uno para todos los sectores? (Creo que debería ser) ¿O diferente?
Ya te lo he dicho: ¡el delantero lo juzgará todo!) Comprueba todo tú mismo, no te fíes de la palabra de nadie.
Lo más importante: debe haber tantos zagueros como delanteros y el conjunto de un zagueros anterior se convierte en el inicio de uno nuevo.
La metodología es la misma, estoy de acuerdo.
¿Qué tal si seleccionas un solo resultado de entre más de 10000 opciones de una prueba retrospectiva? ¿Por el máximo beneficio? O por beneficio máximo con algún nivel de drawdown (selecciono con drawdown < 20%). ¿O otro método de selección?
El criterio de selección del resultado: ¿uno para todos los sectores? (Creo que debería ser) ¿O diferente?
Así que, en primer lugar. La optimización de WF responde a la pregunta: si reoptimizo mi EA cada N días y elijo el mejor resultado (basado en algún criterio/regla/función de adecuación) ¿cómo afectaría al periodo de negociación de M días? (extracto de la teoría)
Es decir, el desarrollador para el experto determina experimentalmente:
1. Criterio personalizado (incrustado en el Asesor Experto) - a discreción del desarrollador - un amplio campo para la discusión (esto es relativo a su drawdown de <20%).
2. Períodos N (en la muestra para la ventana) y M (fuera de la muestra para la ventana). Y es un campo de investigación interesante cambiar N y M en base a algunos criterios del periodo anterior.
3. Parámetros del sistema a optimizar
4. Rango de valores de los parámetros en los que se va a realizar la optimización (es posible limitarlo programáticamente)
Es decir, es obvio que se trata de una clase separada de Asesor Experto con un enfoque especial para el comercio. Tal Asesor Experto (probablemente) no será capaz de mostrar un comercio rentable en el historial incluso para el último año con un conjunto de parámetros, y fallará en el historial después de un mes.
¿Es necesario el WF para otros Asesores Expertos cuyos desarrolladores no han implementado todos estos 4 elementos? Creo que no.
Es decir, sería bueno que un operador seleccionara el "Modo de Comercio" en la lista cuando desee comprobar el Asesor Experto según el escenario recomendado por el programador
¿Por qué el modo comercio? Porque al final emulamos la negociación con la estrategia de sobreoptimización en zonas específicas, eligiendo la mejor por el criterio Custom Max y negociando con los valores de los parámetros definidos en cada paso.
Eso es todo. No proporcione ninguna otra configuración. Pero proporciona al desarrollador una interfaz programática:
- para determinar que se selecciona WalkForward
- fijar la duración de los periodos N y M
Así que, en primer lugar. La optimización de WF responde a la siguiente pregunta: si tuviera que reoptimizar mi EA cada N días y elegir el mejor resultado (basado en algún criterio/regla/función de adecuación) ¿cómo afectaría al periodo de negociación de M días? (extracto de la teoría)
es decir, el desarrollador para el Asesor Experto determina por la experiencia:
1. Criterio personalizado (incrustado en el Asesor Experto) - a discreción del desarrollador - un amplio campo para la discusión (esto es relativo a la reducción del 20%).
2. Períodos N (en la muestra para la ventana) y M (fuera de la muestra para la ventana). Y es un campo de investigación interesante cambiar N y M en base a algunos criterios del periodo anterior.
3. Parámetros del sistema a optimizar
4. Un rango de valores de los parámetros en los que se va a realizar la optimización (es posible limitarlo programáticamente)
Es decir, es obvio que se trata de una clase separada de Asesor Experto con un enfoque especial para el comercio. Tal Asesor Experto (probablemente) no será capaz de mostrar un comercio rentable en la historia incluso para el último año con un conjunto de parámetros, y fallará en la historia después de un mes.
¿Es necesario el WF para otros Asesores Expertos cuyos desarrolladores no han implementado todos estos 4 elementos? Creo que no.
Es decir, sería bueno que un operador seleccionara el "Modo de Comercio" en la lista cuando desee comprobar el Asesor Experto según el escenario recomendado por el programador
¿Por qué el modo comercio? Porque al final emulamos la negociación con la estrategia de sobreoptimización en zonas específicas, eligiendo la mejor por el criterio Custom Max y negociando con los valores de los parámetros definidos en cada paso.
Eso es todo. No proporcione ninguna otra configuración. Pero proporciona una interfaz de programa para el desarrollador:
- para determinar que se ha seleccionado WalkForward
- fijar la duración de los periodos N y M
Técnicamente, para el análisis, el desarrollador puede recopilar información para cada carrera de ida y vuelta a través de los marcos, tal vez añadir información sobre el número de paso de la caminata en el marco.
En la documentación podemos añadir un ejemplo de guardado y visualización de fotogramas para el modo walk-forward en tester, y en kodobase, creo, habrá una variante simple que puede ser modificada para sus propósitos.Pero no es necesario introducir el número de paso, indirectamente, la llegada de la trama con los datos del nuevo paso de la caminata se puede hacer analizando el paso.
es decir, el desarrollador para el Asesor Experto determina por la experiencia:
1. Criterio personalizado (incrustado en el Asesor Experto) - a discreción del desarrollador - un amplio campo de discusión (esto es para su Asesor Experto con drawdown <20%)
2. Períodos N (en la muestra para la ventana) y M (fuera de la muestra para la ventana). Y es un campo de investigación interesante cambiar N y M en base a algunos criterios del periodo anterior.
3. Parámetros del sistema a optimizar
4. Rango de valores de los parámetros en los que se va a realizar la optimización (es posible limitarlo programáticamente)
Es decir, es obvio que se trata de una clase separada de Asesor Experto, con un enfoque especial para el comercio. Tal Asesor Experto (probablemente) no será capaz de mostrar un comercio rentable en el historial incluso para el último año con un conjunto de parámetros, y perderá dinero en el historial en un mes.
¿Es necesario el WF para otros Asesores Expertos cuyos desarrolladores no han implementado todos estos 4 elementos? No lo creo.
1. El comprobador ya contiene los criterios de optimización, así que ¿por qué "meterlos" en el Asesor Experto?
El cambio y la relación de la espalda con el delantero también es objeto de comprobación en el delantero. Si la relación de avance resulta ser mejor, la utilizaremos para el análisis posterior.
3 Los parámetros a optimizar son variables del usuario. Es el propio código el que se somete a prueba.
4. El rango de las variables - se puede buscar programáticamente pero hay muchas sutilezas - por ahora es mucho más seguro y fácil hacerlo manualmente. Y esto es una cuestión de optimización, no de volking-forwarding.
¿Por qué es obvio que se trata de una clase distinta de expertos? Creo que esta clase incluye a TODOS los EAs, ya que TODOS los EAs sin sobre-optimización o sobre-entrenamiento están agotados. El avance sólo demuestra lo rápido que ocurre esto.
Así que, en primer lugar. La optimización de WF responde a la siguiente pregunta: si tuviera que reoptimizar mi EA cada N días y elegir el mejor resultado (basado en algún criterio/regla/función de adecuación) ¿cómo afectaría al periodo de negociación de M días? (extracto de la teoría)
es decir, un desarrollador de Asesores Expertos utilizará su experiencia para determinar:
1. Criterio personalizado (incorporado en el Asesor Experto) - a discreción del desarrollador - un amplio campo de discusión (esto es relativo a su drawdown <20%).
2. Períodos N (en la muestra para la ventana) y M (fuera de la muestra para la ventana). Y es un campo de investigación interesante cambiar N y M en base a algunos criterios del periodo anterior.
3. Parámetros del sistema a optimizar
4. Un rango de valores de los parámetros en los que se va a realizar la optimización (es posible limitarlo programáticamente)
Es decir, es obvio que se trata de una clase separada de Asesor Experto con un enfoque especial para el comercio. Tal Asesor Experto (probablemente) no será capaz de mostrar un comercio rentable en el historial incluso para el último año con un conjunto de parámetros, y fallará en el historial después de un mes.
¿Es necesario el WF para otros Asesores Expertos cuyos desarrolladores no han implementado todos estos 4 elementos? Creo que no.
Es decir, sería bueno que un operador seleccionara el "Modo de Comercio" en la lista cuando desee comprobar el Asesor Experto según el escenario recomendado por el programador
¿Por qué el modo comercio? Porque al final emulamos la negociación con la estrategia de sobreoptimización en zonas específicas, eligiendo la mejor por el criterio Custom Max y negociando con los valores de los parámetros definidos en cada paso.
Eso es todo. No proporcione ninguna otra configuración. Pero proporciona una interfaz programática para el desarrollador:
- para determinar que se ha seleccionado WalkForward
- fijar la duración de los periodos N y M
Pero algo me parece que será difícil. Yo, por ejemplo, sin una base de datos no me he decidido. Un cálculo sencillo:
1 pase de optimización produce más de 10000 líneas
+ 1 pase de avance - otras 10000+ filas
=20000+ filas
* por ejemplo, por segmento de 12 años con sobreoptimización mensual
=240 mil líneas
Si añadimos los datos de todas las operaciones para las curvas de balance y de equidad de los marcos, la cantidad de datos para el análisis aumentará decenas, cientos o miles de veces para los revendedores. Otra variante que consume menos recursos es guardar los datos de la renta variable y del saldo no para cada operación, sino una vez al día, por ejemplo. He calculado la inclinación de la curva para mi Asesor Experto, es decir, he obtenido una cifra y la he introducido en el cálculo de parámetros personalizados para la optimización. Por supuesto, no es tan informativo como la curva (por día o por operación).
Todavía no lo he hecho, pero lo más probable es que introduzca filtros por nivel (por ejemplo, drawdown <20%) + clasificación (beneficio máximo). Es probable que el filtro sea más de uno.
En el terminal, sólo se puede operar con archivos y matrices, lo cual es mucho más laborioso que una consulta SQL.
Por supuesto, es posible adjuntar una base de datos al sistema MT5. Pero no será una solución escalable, porque será muy difícil para un usuario común. Lo estoy haciendo por mí mismo en mi sitio - la carga de archivos de ida y vuelta a través de un formulario en la base de datos seguido por el análisis.
Y nunca he visto la posibilidad de sacar tablas en MT5, como en el navegador. Creo que también habrá algunos problemas con él.
En general, me temo que en MT5 - WF nunca lo será.
1. Los criterios de optimización ya están presentes en el probador, ¿por qué deberían añadirse al Asesor Experto?
¿Está seguro de que esos criterios son suficientes para identificar (de forma automática) el mejor conjunto para el paseo? Al fin y al cabo,elibrarius acaba de estar en este hilo, haciendo una pregunta sobre qué criterio es mejor y quién usa qué. Además, los diferentes enfoques del comercio probablemente requerirán diferentes criterios, en algún lugar el drawdown es muy crítico, en algún lugar el número de operaciones es importante, en algún lugar el beneficio final.
Además, no veo ninguna diferencia con respecto a mi lista.
¿Por qué es obvio que se trata de una clase distinta de Asesor Experto? Creo que esta clase incluye a TODOS los EAs, porque TODOS los EAs sin sobre-optimización o sobre-entrenamiento fallarán. Forward sólo muestra lo rápido que ocurre.
El desarrollador declara que el EA opera en este modo y ha implementado el soporte para WF en el código. Y no sólo cuando el EA empiece a fallar - reoptimizarlo.
Y no se puede establecer N y M en la interfaz del probador - eso es lo que sugerí, sólo programáticamente. Si usted ve lo claro que es para todos para hacer los ajustes en la interfaz de probador, y luego ya se fija - los períodos de N y M se introducirá por el usuario (aunque su"Cambio y la relación de la espalda a la delantera - este es el tema de la comprobación en el delantero" no funcionará), sugieren su versión.