75.000 opciones: ¿4 GB de RAM y 4 GB de caché de disco no son suficientes? - página 6
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
.... Pero, ¿por qué sólo hay 1.000 sobrepasos en un espacio tan grande? Es muy duro. Ejecuté este Asesor Experto en MT4 sobre un área de 1.500 millones de valores y resultó en 4400 rebotes netos en 4 minutos sobre un historial de 18000 barras EURUSD H1. ....
Depende de la calidad de la función objetivo (fitness).
- max NetProfit
- max NetProfit y min DD
- max NetProfit y max PF
- ¿algo más?
No he visto esa función de destino en su código. Esto es lo que tenemos como parámetros de optimización:Además, utilizamos el algoritmo original, que es un orden de magnitud más rápido que otros algoritmos que conocemos.
Dudo mucho de las 100-200 carreras. ¿Qué población se utiliza? 16? :) Cuando se empieza con un área de búsqueda grande se pueden obtener fácilmente 256 excesos en la primera generación sobre 256 poblaciones en la estimación inicial. Esta es la variante más sucia. ¿Es esto lo que quieres decir (ejecutar la primera población y parar)? ¿Cree en los resultados de 100-200 carreras en un enorme campo de variantes? ¿Quién necesita resultados tan sucios?1000 ejecuciones es demasiado, yo suelo utilizar 100-200 ejecuciones (para cualquier número de parámetros) para evaluar una solución.
Esto es lo que obtuve cuando ejecuté la Muestra MACD en 198 build en sus condiciones iniciales de la primera página de este hilo:
A partir de un área de búsqueda de 35.000 millones de sobremuestras, se realizaron 12800 ejecuciones en 8 minutos y 46 segundos sobre un historial de 18691 barras en modo "por precio de apertura". Se adjunta el informe del mejor caso.
Además, hay muchas preguntas sobre los datos incoherentes (todos de sus informes en el archivo ZIP). Los beneficios, el número de operaciones, etc. no se acercan en absoluto a los datos del informe TSGO (el archivo XLS está hecho para la ejecución 880, como se indica en la última página del informe).
Además, ¿por qué el TakeProfit está en 80 pips y el trailing stop en 6700?
¿Cuál es la explicación de todo esto? Parece que su prueba es tan defectuosa que no se puede tener en cuenta de ninguna manera.
Las pruebas/explicaciones deben ser sencillas y fáciles de entender, no confusas hasta el punto de tener que hacer preguntas como ésta. Una captura de pantalla que no muestra nada y un archivo con datos incoherentes es una prueba para los que son demasiado perezosos para averiguarlo.
Es posible que no esté claro sobre la marcha...
Permítanme explicar los resultados.
1. El criterio de optimización puede ser arbitrario.
(sobre la función de destino)
La calcula el propio usuario y la pasa a TSGO.
Es decir, puede utilizar tanto los que tiene como cualquier otro que se le ocurra a un usuario.
Por ejemplo, se puede utilizar el criterio de los pagos esperados.
(es decir, la probabilidad de que los tratos tengan un resultado esperado positivo, o en otras palabras, que el sistema funcione en el lado positivo)
. O bien, algún criterio que describa la linealidad de la equidad (ayuda a resolver problemas similares a la optimización Walk Forward) ...
El criterio de optimización juega un papel crucial en la optimización.
(para obtener el resultado correcto, no CurveFitting)
2. La optimización puede hacerse simultáneamente según muchos criterios.
(sobre la función del objetivo)
Sólo tengo un prototipo de la próxima versión de TSGO en casa.
En él se pueden establecer varios criterios de optimización simultáneamente (véase la función TS.GO.Criterion(...)).
En el ejemplo de la tabla del visor los criterios utilizados están resaltados con fondo amarillo - son NetProfit, MaxDD, ProfitFactor.
Es decir, TSGO buscó sistemas en torno al máximo de estos tres criterios (MaxDD en Omega es con signo menos).
Es decir, buscó sistemas con grandes beneficios, con gran ProfitFactor y mínimo DrawDown.
Se pueden obtener resultados interesantes maximizando simultáneamente el NetProfit para cada año (o mes),
es decir, buscando sistemas con buenos resultados para cada año o incluso mes en el historial.
(en TSGO los criterios de optimización se pueden establecer hasta 1000, en realidad he probado hasta ahora unos 150-200 - esto es NetProfit por meses en MSFT)
3. El tamaño de nuestra población es de hasta 1000 ejemplares (podríamos hacer más, pero parece que es demasiado).
(Dudo mucho que haya 100-200 carreras. ¿Qué tipo de población se utiliza? 16? :))
En ese ejemplo concreto, creo que era 100 (véase el valor del parámetro en TS.GO.Popul(...))
Suelo utilizar poblaciones de 50 a 100, a veces de 1000.
En general esto tiene poco efecto, siempre se puede poner a 1000, no tiene casi ningún efecto en la velocidad de búsqueda.
Los resultados son muy precisos, incluso con 500 ejecuciones con una población de 1000 ... :))
Le dije que estoy usando mi propio algoritmo original, que hasta ahora en el Internet no han visto nada.
Es mucho más rápido que todos los demás algoritmos que conozco (y que probablemente usas tú).
El tamaño de la población en él no importa (siempre que no sea demasiado pequeño) ...
¿Es esto lo que quieres decir (ejecutar la primera población y parar)?
Eso es lo que dices, a mí me funciona de otra manera.
¿Cree en los resultados de 100-200 carreras en un enorme campo de variantes?
Es más, estoy bastante seguro de que los resultados de CS son independientes del número de variantes en el espacio de parámetros.
¿Quién necesita resultados tan sucios?
No son desordenados, son razonablemente suficientes.
Nunca se garantiza la obtención de resultados precisos en CS.
La única manera de obtener un resultado exacto es hacer un rebasamiento completo.
Es decir, siempre tienes una estimación, un resultado aproximado.
Mi algoritmo puede obtener una buena estimación en la mayoría de los casos a partir de 100-200 carreras.
De un área de búsqueda de 35 mil millones de búsquedas, se hicieron 12800 ejecuciones
En mi algoritmo 2000 ejecuciones fueron más que suficientes.
Desgraciadamente sus informes no son tan simples e indicativos como los de MetaTrader. Has publicado el archivo de informe XLS de Omega con el número de ejecución de población 880, aunque no hay ninguna descripción de los parámetros encontrados de esta ejecución 880 en ningún sitio (ni en el propio informe XLS, ni en el informe TSGO, ni en las capturas de pantalla de este hilo).
Qué hacer...
Si Omega Research comprara nuestro TSGO y lo incorporara a su paquete, entonces sería sólo una casilla de verificación como la suya.
Pero por ahora es sólo un complemento de TradeStation.
Todo es correcto con los resultados.
La ejecución 880 es la mejor según Omega (por el criterio NetProfit),
pero no es la mejor según TSGO (simultáneamente por los criterios NetProfit, MaxDD, ProfitFactor)
TSGO utiliza Omega sólo para la organización de los by pass del bucle.
Además, puedes seleccionar cualquier criterio disponible en Omega, y no afecta al trabajo de TSGO.
TSGO realiza la optimización basándose en los criterios especificados por el usuario en el código de la señal.
El número de la carrera obtenida en Omega tampoco juega ningún papel.
Cuando la optimización se ha completado, los resultados se dan para la instancia desde la primera línea del visor.
Además, hay muchas preguntas sobre los datos incoherentes (todo esto proviene de sus informes en el archivo ZIP). Los beneficios, el número de operaciones, etc. no se acercan en absoluto a los datos del informe TSGO (el archivo XLS está hecho para la ejecución 880, que se indica en la última página del informe).
Sí, uno puede tener esa sensación, has hecho un gran trabajo analizando mi ejemplo... :))
Es necesario hacer una pequeña aclaración al respecto.
La cuestión es que TSGO utiliza una característica de Omega para informar del mejor sistema encontrado.
El mejor sistema es la primera línea del visor, sustituya sus parámetros y verá una coincidencia total de los resultados con el informe.
Omega busca el sistema según su criterio (no nos importa cuál),
TSGO busca el sistema según su criterio, establecido en la señal por el usuario.
Durante el proceso de optimización, Omega cambia el parámetro Gen de 1 a K (este es el parámetro de optimización establecido en Omega).
El valor de Gen se envía a TSGO.
Si Gen aumenta, entonces TSGO emite los parámetros del nuevo candidato para probar los resultados de la ejecución.
Si Gen no aumenta, entonces TSGO considera que la optimización ha terminado (Omega recalcula el mejor resultado en su opinión),
en este caso TSGO emite los parámetros de la mejor instancia encontrada (desde la primera línea del visor).
En general, cuando la optimización está completa, el informe Omega muestra los resultados de la instancia desde la primera línea del visor.
Compara sus parámetros y son exactamente iguales.
Todo esto se debe a que TSGO es un complemento de Omega y no una parte de ella.
No hay otra forma de hacerlo.
============================================================================
Renat, te aseguro que son datos absolutamente reales, y todo lo que contiene es absolutamente correcto.
La confusión surge porque no somos los desarrolladores de Omega y no podemos construir el optimizador dentro de Omega.
¿Crees en los resultados de 100-200 carreras en un enorme campo de variantes?
No seas creyente. ¿Sería tan amable de demostrar su punto de vista en este recuento:Así es. Además, estoy bastante seguro de que los resultados de CS no dependen del número de variantes en el espacio de parámetros.
Todo es correcto con los resultados.
Así que:La carrera 880 es la mejor según Omega (según el criterio de NetProfit),
pero no es el mejor según TSGO (por criterios de NetProfit, MaxDD, ProfitFactor simultáneamente)
- No has enumerado los mejores parámetros de ejecución encontrados 880
- Nos dices que "lo negro es blanco", justificándolo con las peculiaridades de tu complemento
- Enviaste un informe Omega incorrecto a sabiendas
- No has indicado exactamente qué función objetivo has utilizado para obtener los resultados de 1000 ejecuciones, y en su lugar has pasado al modo "puedes hacer esto o aquello" (el programador puede establecer el criterio en el código por sí mismo - muestra este criterio en tu código EL)
No me _confirmes_. Mejor _probar_ en números e informes. Nos has obligado a pasar al ámbito de la resolución de problemas a nivel de "caballos en un vacío esférico" (gracias por ello), nos hemos movido y hemos resuelto el problema. Pero no lo ha resuelto de ninguna manera, e incluso nos ha engañado con informes erróneos.Todo lo que has citado antes como prueba desde el principio de este hilo es un auténtico disparate con juegos de palabras. No hay pruebas, sólo un juego de números extravagantes. ¿Sería usted tan amable de tomar el IBM Daily desde 1970 hasta 1999 (exactamente desde principios de 1970 hasta principios de 1999) y ejecutar los límites anteriores (exactamente los suyos) y publicar dicho informe para que no haya ninguna reclamación al respecto? Y yo publicaré la mía.
¿Y por qué siempre tengo que poner excusas aquí?
Si quieres que abandone el foro, por favor.
Prohíbeme aquí también, y haré más trabajo y menos distracciones.
Si no entiendes algo, no significa que te hayan mentido.
Sólo significa que no entiendes, y en la sociedad educada.
la gente sólo pide explicaciones de las cosas que no entiende.
La gente suele juzgar a los demás por sí misma.
Por mi parte, nunca he cuestionado la honestidad de los participantes en el foro.
(A diferencia de ti...).
Responderé por orden.
1. En uno de mis posts escribí:
Además, utilizamos el algoritmo original, que es un orden de magnitud más rápido que otros algoritmos que conocemos.
1000 ejecuciones es demasiado, para estimar una solución suelo utilizar 100-200 ejecuciones (para cualquier número de parámetros).
Me has respondido:
¿Ustedmismo cree en los resultados de 100-200 carreras en un enorme campo de variantes?
No tengas fe. ¿Sería tan amable de demostrar sus palabras sobre este recálculo?Sí. Además, estoy absolutamente seguro de que los resultados de CS no dependen del número de variantes en el espacio de parámetros.
---
¿Qué tengo que demostrarte?
¿Ese "suelo utilizar 100-200 ejecuciones (para cualquier número de parámetros)"?
¿Y considero que tales resultados son suficientemente fiables?
Esa es mi opinión, y ¿por qué debería probarla?
¿No lo crees? - Está en su derecho.
Puedes decir simplemente: "No lo creo".
Habrá dos opiniones sobre el mismo tema.
2. No ha dado una lista de los mejores parámetros encontrados para la ejecución del 880
La carrera 880 no es la mejor en términos de TSGO,
y puede que ya no esté en la población.
La mejor carrera es 919, que se muestra en la primera línea del visor de TSGO.
Es el que se ve en el informe Omega.
Compara.
En el visor, línea 1.
Gen = 919 (es el número de la carrera)
Operaciones = 52
Beneficio neto = 29312,07
MaxDD = -4939,19
FP = 7,42
En el informe Omega
Beneficio neto total = 29.312,07 dólares
Número total de operaciones = 52
Reducción máxima intradía = (4.939,19 $)
Factor de beneficio = 7,42
Por qué Omega hizo la carrera número 880, he escrito en un mensaje anterior.
3. Me has enviado un informe falso de Omega.
Envié un informe deliberadamente falso Omega, mira más cuidadosamente.
4. No ha especificado exactamente qué función objetivo ha utilizado para obtener los resultados de 1000 ejecuciones
Ya lo escribí en mi post anterior, la optimización se realizó simultáneamente utilizando tres criterios - NetProfit, MaxDD, ProfitFactor. Se destacan en el visor con fondo amarillo.
En el código de la señal en Easy se definen mediante la función TS.GO.Criterion
Aquí hay un fragmento de código:
R = TS.GO.Method(1); -- que permite la optimización multicriterio.
R = TS.GO.Criterion("NetProfit",1); -- primer criterio
R = TS.GO.Criterion("MaxDD",1); -- segundo criterio
R = TS.GO.Criterion("PF",1); -- tercer criterio
Los valores de los criterios se asignan al final del código en la última barra:
R = TS.GO.Set("NetProfit",NetProfit);
R = TS.GO.Set("MaxDD",MaxIDDrawDown);
R = TS.GO.Set("PF",GrossProfit/(0.001-GrossLoss));
No tengo ningún deseo de escuchar sus ataques.
Si vamos a hablar, tenemos que estar en igualdad de condiciones.
¿Está de acuerdo?
Entonces, por favor, intente demostrar sus afirmaciones.
1. Enviaste un informe obviamente falso a Omega.
2. No ha indicado exactamente qué función objetivo ha utilizado para obtener sus resultados.
3. Y tú mismo no lo has resuelto de ninguna manera, y además lo has desvirtuado con informes incorrectos.
4. Todo lo que has dado antes como prueba desde el principio de este hilo es una absoluta tontería con juego de palabras. (Esto no es sólo una afirmación, es ya un insulto)
5. No hay pruebas, sólo un juego de números extravagantes.
Sigo sugiriendo que se pase del ámbito de los juegos de palabras únicamente al de los informes prácticos. La última vez sugerí que el problema se resolviera de nuevo. ¿Puede resolverlo y publicar informes que sean incuestionables?
Después de esta tarea, podemos pasar sin problemas a una declaración sobre la suficiencia de 100-200 ejecuciones en campos enormes de variantes.
Sólo hubo un malentendido con el número de ejecución de Omega.
En el siguiente post te explico con detalle de qué se trata.
Sobre la suficiencia de 100-200 carreras en campos de variantes enormes.
No he hecho ninguna declaración ni afirmación.
Literalmente escribí lo siguiente:
... Suelo utilizar 100-200 ejecuciones (para cualquier número de parámetros) para estimar una solución
¿Entiendes la diferencia entre "estimación" y "suficiencia"?
Esto es especialmente interesante cuando se trata de informes y pruebas, ya que suelo pedirlos, simple y llanamente. Necesita informes informáticos con un máximo de una línea de comentario del autor cada uno.
Estaría encantado de explicarlo en dos palabras, pero si no lo entiendes, tengo que escribir posts kilométricos...
Después de esta tarea...
¿Y me contrataste para darme tareas?
Sigo esperando que demuestres tus CONCLUSIONES.
Si hace afirmaciones técnicas escandalosas, tenga la amabilidad de demostrarlas.
Ya hemos tratado con 100-200 carreras y resultaron ser resultados absolutamente sucios (aunque "estimados") (lo dije enseguida, pero no estuviste de acuerdo). Y sólo lo admitiste bajo presión.
No hago afirmaciones técnicas extravagantes.
Para ser más precisos, para usted pueden estar fuera de los límites, pero para mí son bastante ordinarios, de trabajo.
Ya hemos tratado con 100-200 carreras y resulta que son resultados absolutamente sucios (aunque "estimados") (lo dije enseguida, pero no estuviste de acuerdo). Y esto sólo tuvo que admitirlo bajo presión.
No son resultados "absolutamente sucios", sino bastante factibles.
Y no acepté nada bajo ninguna presión.
He dicho lo mismo todo el tiempo, puedo decirlo de nuevo.
Especialmente para ti,
He realizado otra optimización en Omega.
Sólo he dejado un criterio de optimización -el beneficio neto- para facilitarte la tarea.
El mismo criterio se utilizó en Omega.
Hubo 1000 carreras en total.
IBM, 7800 barras, hasta 1999/12/31
(Omega no tiene fecha de inicio de periodo, tiene fecha de finalización y número de barras)
Pruebas en barras diarias por cierre de barra (por apertura Omega no lo hace)
Stops, toes y trailing en código realizados por órdenes pendientes,
ya que Omega dentro de barra no funciona de otra manera y los datos solo tienen barras diarias.
En el anexo:
@Renat.txt - Código de la señal EL, difiere del anterior en que sólo queda un criterio.
1000.XLS - Informe del sistema Omega (mejor ejecución según Omega)
SOR.xls - Informe de pruebas Omega (todas las ejecuciones)
TSGO-1000.CSV - Composición de la última población en TSGO (tamaño de la población 100).
El bloque de definición de criterios ha sido modificado en el código de la señal:
R = TS.GO.Method(1);
R = TS.GO.Criterion("NetProfit",1); -- segundo parámetro = 1 - buscando el criterio máximo
R = TS.GO.Criterion("MaxDD",0); -- segundo parámetro = 0 - la optimización por criterio está desactivada
R = TS.GO.Criterion("NetProfit",1).GO.Criterion("PF",0); -- segundo parámetro = 0 - la optimización por criterio está desactivada
Tenga en cuenta
1. La primera línea del visor corresponde a la primera línea de la población y corresponde a los resultados en Omega.
2. el número de la mejor ejecución en el visor es 401, en Omega 948, si se mira en SOR.xls se verá que estas ejecuciones tienen los mismos resultados. TSGO rechaza los resultados repetidos de las coincidencias.
3. Si observa la composición de la última población, verá que el mejor resultado encontrado tiene NetProfit 1891,86 (en 401 ejecuciones), el resultado de 213 ejecuciones es 1814,16, el resultado de 93 ejecuciones es 1796,40. Es decir, el resultado de la 93ª ejecución fue diferente del mejor resultado después de 1000 ejecuciones en un 5,3%, lo que creo que no está mal y puede considerarse como una buena estimación de NetProfit.
A continuación se muestra una captura de pantalla