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
I updated to last version of BestInterval and Virtual.
When compile with new lines at the beginning of the code got many errors. At the end only 3 (see image).
Thank you very much for your help
Put these lines at the beginning, not at the end.
Normalmente un backtest de este tipo va directo a la papelera justo durante la Optimización (o una sola pasada)
Sin embargo, BestInterval durante la Optimización este pase mostrará uno de los mejores. Razón
La desventaja es que no hay métricas para determinar cuánto no se ajusta al intervalo que se está optimizando
Por ejemplo, mi librería dibuja exactamente lo mismo para 1 pasada en el tester, pero no desecha intervalos, sino que voltea las operaciones perdedoras y aproxima una nueva secuencia.
resulta que cuantos más trades haya en el TS inicial, más bonitos dibujos mostrará Bestinterval, y no importa qué distribución de trades había antes de eso.
La desventaja es que no hay métricas para determinar hasta qué punto no se ajusta al intervalo que se está optimizando
Puede escribir cualquier métrica que desee para OnTester. La librería lo permite.
por ejemplo, mi libreria dibuja exactamente lo mismo para 1 pasada en el tester, solo que no desecha intervalos, sino que invierte las operaciones perdedoras y aproxima una nueva secuencia
Resulta que cuantos más trades haya en el TS inicial, más bonitos cuadros mostrará Bestinterval, y no importa qué distribución de trades había antes de eso.
Afirmación ambigua. Determino el ajuste simplemente - tomo UN mejor resultado de BestInterval y lo ejecuto (solo) en un intervalo dos veces más grande. Si la extensión del intervalo no cambia el carácter del balance directo - no es un ajuste. En la segunda figura de arriba > 1000 operaciones. Si duplico el intervalo, la línea recta se mantiene. Es decir, no es un ajuste al 100%.
Otra cosa es que "no se ajusta" significa sólo una cosa - los patrones se encontraron real. Pero nada garantiza que vayan a continuar. Y esta falta de garantía no indica ningún tipo de ajuste. Es sólo una ley de vida.
Puede escribir cualquier métrica para OnTester. La biblioteca permite.
Declaración ambigua. Yo defino ajuste simplemente - tomo UN mejor resultado de BestInterval y lo ejecuto (simple) en un intervalo dos veces más grande. Si la extensión del intervalo no cambia el carácter del balance directo - no es un ajuste. En la segunda figura de arriba > 1000 operaciones. Si duplico el intervalo, la línea recta se mantiene. Es decir, no es un ajuste al 100%.
Otra cosa es que "no se ajusta" significa sólo una cosa - los patrones se encontraron real. Pero nada garantiza que van a continuar. Y esta falta de garantía no indica ningún tipo de ajuste. Es sólo una ley de la vida.
En general, estás haciendo puro aprendizaje automático, pero por alguna razón ignoras ese tema :)
Sí, si se incorporan algunas métricas y se seleccionan los modelos en función de ellas, se reduciría la rutina de sobreajuste, a eso me refiero. Idealmente, si la máquina seleccionará el mejor, que es más probable que muestre algo en OOS también
En general, estás haciendo aprendizaje automático puro, pero por alguna razón estás ignorando ese tema :)
No puedo soportarlo.
sí, si usted construye en algunas métricas y tamizar los modelos basados en ellos, sólo reduciría la rutina de búsqueda, ese es mi punto. Idealmente, si se seleccionará automáticamente el mejor, que con una mayor probabilidad en el OOS también mostrará algo.
Bueno, si hubiera órdenes de magnitud más recursos computacionales, no se necesitaría BestInterval. Es decir, no hay ningún indicio de MO aquí. Es sólo un filtro cómodo y rápido de aplicar, nada más.
En cuanto a la probabilidad de OOS, se determina exactamente como he dicho anteriormente. Es decir, se elimina cualquier factor de selección/optimización. O todo es estupendo o es basura.
Cuestión mucho más complicada es cuando hay una ST funcionando y es necesario seleccionar valores de parámetros de entrada óptimos para lo real.
Se convirtió en un descubrimiento para mí que GA + BestInterval es un mapeo repugnante. Es decir, se produce una convergencia a algún extremo local y, cuando se comprueba, resulta ser un ajuste absoluto.
Resulta que Buteforce+BestInterval es un mapeo excelente. Mucho, donde GA me hizo creer que el TC era basura, Bruteforce se mostró prometedor.
Bueno, para que Bruteforce sea rápido, necesitas un pequeño número de ticks, y una lógica TC rápida. Por eso todos los mecanismos de aceleración dan resultados no sólo cuantitativos, sino también cualitativos.
El propio AG es tan bueno como la leche de un toro ) Se considera una optimización exploratoria, que no debe nada a la fiabilidad de los resultados.
No puedo hacerme amigo de GA.