El sistema perfecto de comercio mecánico. - página 4

 
sashken писал (а):
eugenk1 escribió:
Hasta ahora, todo me parece mucho más sencillo. Deberías empezar con algún sistema sencillo e ingenuo, con un mínimo de parámetros de ajuste. Y añadirle un bloque de cambios de parámetros adaptativos en tiempo real...

Ya está, queda muy poco por hacer :) Tenemos que decidir qué datos utilizar para calcular los parámetros de adaptación. Ni siquiera sé qué sugerir :(
¿Alguien tiene alguna idea al respecto?

Puedo empezar proponiendo el siguiente modelo de CT:
Tomamos un Asesor Experto simple y le escribimos un bloque "tester" (cuya tarea será - una vez al día por ejemplo a las 01:00 GMT ajustar el TS bajo el historial mensual).
 
xeon, se puede hacer que el probador funcione todo el tiempo. Por supuesto, tendría que estar escrito en C altamente optimizado, no en mql4. Por desgracia, hay un escollo muy serio en todo esto. Es decir, es el periodo de estimación y optimización del sistema. Es decir, ¿durante cuánto tiempo hay que evaluar su rendimiento? Supongamos que tenemos dos estrategias que compiten por el derecho de negociación real. El actual exitoso y el peor. En una hora, por ejemplo, la estrategia actual ha perdido dinero, mientras que la estrategia de respaldo, por el contrario, tuvo éxito. La cuestión es cambiar de estrategia o no cambiar. Al fin y al cabo, esto puede ser el comienzo de una nueva tendencia (¡no confundir con tendencia/flotación!), o puede ser accidental. Es decir, resulta que un probador de este tipo tendría al menos un (¡¡¡importante!!) parámetro configurable: el periodo de evaluación y optimización. No piense que estoy diciendo que ese enfoque es imposible. Sólo digo que hay dificultades y lugares oscuros en todo esto.
 
eugenk1 писал (а):
xeon, se puede hacer que el probador funcione todo el tiempo. Por supuesto, tendría que estar escrito en C altamente optimizado, no en mql4. Por desgracia, hay un escollo muy serio en todo esto. Es decir, es el periodo de estimación y optimización del sistema. Es decir, ¿durante cuánto tiempo hay que evaluar su rendimiento? Supongamos que tenemos dos estrategias que compiten por el derecho de negociación real. El actual exitoso y el peor. En una hora, por ejemplo, la estrategia actual ha perdido dinero, mientras que la estrategia de respaldo, por el contrario, tuvo éxito. La cuestión es cambiar de estrategia o no cambiar. Al fin y al cabo, esto puede ser el comienzo de una nueva tendencia (¡no confundir con tendencia/flit!), o accidental. Es decir, resulta que un probador de este tipo tendría al menos un (¡¡¡importante!!) parámetro configurable: el periodo de evaluación y optimización. No piense que estoy diciendo que ese enfoque es imposible. Sólo digo que hay dificultades y lugares oscuros en todo esto.

Intentemos un enfoque sencillo después de todo.
La tarea: ¿es posible escribir una función que ejecute el historial mensual una vez al día y establezca el número óptimo para el parámetro de pérdidas de parada?
Y LO MEJOR: ¿Puedo utilizar esta función para comprobar el probador? ¿Funcionará el probador en absoluto? Resulta que cada día en el modo de prueba debe cambiar el parámetro de parada para un nuevo día? ¿Es posible? Si se resuelve esta tarea, el resto es la guinda, como ya se ha dicho.
 
y si el trailing stop depende del matzod, ¿se puede llamar sma adaptativo?
 
quality писал (а):
eugenk1 escribió (a):
xeon, se puede hacer que el probador funcione todo el tiempo. Por supuesto, tendría que estar escrito en C altamente optimizado, no en mql4. Por desgracia, hay un escollo muy serio en todo esto. Es decir, es el periodo de estimación y optimización del sistema. Es decir, ¿durante cuánto tiempo hay que evaluar su rendimiento? Supongamos que tenemos dos estrategias que compiten por el derecho de negociación real. El actual exitoso y el peor. En una hora, por ejemplo, la estrategia actual ha perdido dinero, mientras que la estrategia de respaldo, por el contrario, tuvo éxito. La cuestión es cambiar de estrategia o no cambiar. Al fin y al cabo, esto puede ser el comienzo de una nueva tendencia (¡no confundir con tendencia/flotación!), o puede ser accidental. Es decir, resulta que un probador de este tipo tendría al menos un (¡¡¡importante!!) parámetro configurable: el periodo de evaluación y optimización. No piense que estoy diciendo que ese enfoque es imposible. Sólo digo que hay dificultades y lugares oscuros en todo esto.

Intentemos un enfoque sencillo después de todo.
El problema: ¿es posible escribir una función que ejecute el historial de un mes una vez al día y establezca el número óptimo para el parámetro de stop loss?
Y LO MEJOR: ¿Puedo utilizar esta función para comprobar el probador? ¿Funcionará el probador en absoluto? Resulta que cada día en el modo de prueba debe cambiar el parámetro de parada para un nuevo día? ¿Es posible? Si se resuelve esta tarea, el resto es la guinda, como ya se ha dicho.

Por lo que sé, es posible escribir tal función en mql, pero esta tarea no es fácil para mí, porque soy un "programador aficionado" y necesito tiempo para hacerlo.
 

Los indicadores autoajustables son un callejón sin salida. Intentaré justificar mi opinión.
He desarrollado varios indicadores de este tipo, pero parecían ser sensibles a la volatilidad de las cotizaciones procedentes de diferentes empresas de corretaje. Es decir, estos indicadores funcionan bien con los datos de una empresa de corretaje y no funcionan en absoluto con los datos de otra. Lo peor de todo es que trabajan con datos de TC. Por ejemplo en los indicadores estándar en el mismo intervalo de cotizaciones hay divergencia en una empresa de corretaje y no en otra.
Mi investigación demostró que la volatilidad es el principal factor a tener en cuenta en un indicador de autoajuste. Sin embargo, con el tiempo el indicador se vuelve dependiente del método de filtrado de las cotizaciones en las diferentes empresas de corretaje y de los cambios de este método (que no es notificado por las empresas de corretaje).
Aquí también me encuentro con el hecho de que no puedo "endurecer" (como siempre dice Renat) el autoajuste, porque es constante (lineal), y no discreto.

Creo que la única manera de evitar el problema de la volatilidad es ignorar los valores absolutos de los indicadores y las cotizaciones. Es decir, para tomar una decisión en MTS debemos utilizar la correlación de valores de una u otra forma, y esto es de hecho el reconocimiento de patrones.



 
ArtemRG
¡debe ser así!
 
ArtemRG:

Los indicadores autoajustables son un callejón sin salida. Intentaré justificar mi opinión.
He desarrollado varios indicadores de este tipo, pero parecían ser sensibles a la volatilidad de las cotizaciones procedentes de diferentes empresas de corretaje. Es decir, estos indicadores funcionan bien con los datos de una empresa de corretaje y no funcionan en absoluto con los datos de otra. Lo peor de todo es que trabajan con datos de TC. Por ejemplo en los indicadores estándar en el mismo intervalo de cotizaciones hay divergencia en una empresa de corretaje y no en otra.
Mi investigación demostró que la volatilidad es el principal factor a tener en cuenta en un indicador de autoajuste. Sin embargo, con el tiempo el indicador se vuelve dependiente del método de filtrado de las cotizaciones en las diferentes empresas de corretaje y de los cambios de este método (que no es notificado por las empresas de corretaje).
Aquí también me encuentro con el hecho de que no puedo "endurecer" (como siempre dice Renat) el autoajuste, porque es constante (lineal), y no discreto.

Creo que la única manera de evitar el problema de la volatilidad es ignorar los valores absolutos de los indicadores y las cotizaciones. Es decir, para tomar una decisión en MTS debemos utilizar la correlación de valores de una u otra forma, y esto es esencialmente reconocimiento de patrones.



No estoy de acuerdo con la afirmación "Los indicadores autoajustables son un callejón sin salida". Aunque estoy de acuerdo con ella en otros aspectos. Sólo pienso que puede haber muchas soluciones para las mismas tareas. Por ejemplo en una pregunta: - "cargar" (de lo que siempre habla Renat) la auto-sintonía. - He encontrado una solución un poco diferente, a saber, no cargar los valores de los indicadores, sino utilizar filtros que reduzcan el nivel de "ruido".
 
¿Puedo darte una pequeña pista? :)

Para cualquier sistema, lo importante no son los valores de los precios, sino la velocidad de cambio de los mismos (a veces sólo el signo).
A veces se utiliza la aceleración del precio (estimando la fuerza que actúa sobre el precio, como indicador adelantado).
De hecho, TODOS los indicadores utilizados con MTS están diseñados para estimar la velocidad.
Los diferentes indicadores son simplemente diferentes OPCIONES para estimar la velocidad.

1. TODOS los osciladores estiman la velocidad, a veces la aceleración (como el MACD).

2. TODOS los promedios móviles NUNCA se utilizan por sí solos,
sólo en comparación con otras medias móviles (el precio es un muving con longitud = 1).
Esta comparación de las medias móviles (en realidad comparando su diferencia con cero) es un oscilador.

3. No hay que tener en cuenta el precio, sino el logaritmo del precio.
En los logaritmos todo se vuelve más sencillo y correcto.
Para pequeños cambios en el precio, no habrá diferencia entre trabajar con el precio y el logaritmo,
Con grandes cambios en el precio, la diferencia será significativa.
 
Mak писал (а):
¿Puedo darte una pequeña pista? :)

Para cualquier sistema, lo importante no son los valores de los precios, sino la velocidad de cambio de los mismos (a veces sólo el signo).
A veces se utiliza la aceleración del precio (estimando la fuerza que actúa sobre el precio, como indicador adelantado).
De hecho, TODOS los indicadores utilizados con MTS están diseñados para estimar la velocidad.
Los diferentes indicadores son simplemente diferentes OPCIONES para estimar la velocidad.

1. TODOS los osciladores estiman la velocidad, a veces la aceleración (como el MACD).

2. TODOS los promedios móviles NUNCA se utilizan por sí solos,
sólo en comparación con otras medias móviles (el precio es un muving con longitud = 1).
Esta comparación de las medias móviles (en realidad comparando su diferencia con cero) es un oscilador.

3. No hay que tener en cuenta el precio, sino el logaritmo del precio.
En los logaritmos todo se vuelve más sencillo y correcto.
Para pequeños cambios en el precio, no habrá diferencia entre trabajar con el precio y el logaritmo,
En caso de grandes cambios de precios, la diferencia será significativa.

¿O tal vez también participe en la redacción del código? :-), ¡con tu experiencia en programación iría mucho más rápido!

Razón de la queja: