Necesito un buen archivo histórico para EURUSd - página 4

 

schnappi, naturalmente la metodología para identificar (y eventualmente remediar) los malos ticks y los agujeros de datos es en sí misma un proceso evolutivo. Empecé con el enfoque estándar de los filtros definidos externamente (si la delta del precio > X, entonces tenemos un mal tick, etc.) y el problema con eso es que obligas al conjunto de datos a ajustarse a tus percepciones y expectativas de cómo deberían ser los datos de los precios, lo cual puede o no ser representativo de las características estadísticas intrínsecas de la dinámica de la evolución del precio del instrumento financiero.

Con el tiempo, mi método ha llegado a un punto en el que simplemente requiero que los datos sean coherentes con las características intrínsecas del propio instrumento financiero (en este caso, el par de divisas, pero es aplicable a todos los casos). Lo que esto significa en la práctica es que tomo un tramo de "buenos datos de mercado conocidos" y caracterizo sólidamente sus atributos: brechas de tiempo, brechas de precio, etc. Esto genera un perfil de la evolución natural/característica de los precios para el par de divisas (que será específico del corredor, ya que cada corredor tiene sus propios algoritmos sutiles de "bombeo y pulso" para mantener la alimentación de los precios "viva").

Armado con estos datos de caracterización, hago que el script itere a través de los períodos de tiempo más antiguos y cuestionables, evaluando cada barra en función de si es estadísticamente consistente con la naturaleza inherente del par de divisas. Por ejemplo, digamos que observamos que la brecha de precios que ocurre entre velas M1 sucesivas para el USDJPY es generalmente <3pips. Es decir, la oferta de cierre de la vela N+1 suele estar entre -3 y +3 pips de distancia de la oferta de apertura de la vela N.

Esta es una métrica fácil de generar las estadísticas, simplemente analice el cierre(i+1)-apertura(i) para sus datos y genere un histograma: (tenga en cuenta que excluyo específicamente/intencionadamente las brechas de precios que provienen de los pares de velas que a su vez tienen una brecha de tiempo entre ellos para esta fase de la caracterización)


Ahora bien, si usted evalúa los datos históricos para algún año anterior, digamos 2003, y su script observa una brecha de precios entre velas sucesivas (sin brecha de tiempo) que está muy fuera del rango estadísticamente consistente (para este ejemplo digamos que se detecta una brecha de 50pip) entonces su script tiene motivos para considerar que los datos de precios bajo evaluación en ese momento son sospechosos.

Lo que se hace con las velas sospechosas (la fase de remediación) es otra cuestión, pero aquí hay un ejemplo:


Hay peligros y trampas que hay que evitar en la remediación de los datos, usted puede, sin saberlo, causar más daño que bien si no es cuidadoso en la forma de definir su lista de desalojo de velas malas, así como sus reemplazos (considero simplemente la eliminación de la vela del registro hst como una política de reemplazo también, la sustitución de una brecha de precio malo con una brecha de tiempo artificial en ese caso).

 
Phillip, es un material interesante, pero me parece demasiado arriesgado y que requiere mucho tiempo. Prefiero utilizar fuentes en las que pueda confiar que intentar 'arreglar' fuentes en las que no pueda...

Respecto a esas velas 'sospechosas'. Muchos corredores tienen picos de precios extraños por diversas razones. En tu ejemplo de arriba, ¿cómo sabes que es un dato obvio de "mal tick"? Los picos como ese ocurren...
 
gordon wrote >>
Phillip, es un material interesante, pero me parece demasiado arriesgado y que requiere mucho tiempo. Prefiero utilizar fuentes en las que pueda confiar que intentar 'arreglar' fuentes en las que no pueda...

Respecto a esas velas 'sospechosas'. Muchos corredores tienen picos de precios extraños por diversas razones. En tu ejemplo de arriba, ¿cómo sabes que es un dato obvio de "mal tick"? Los picos como ese ocurren...


En este caso, con este corredor, un análisis detallado de más de 3 años de datos mostró que tal pico nunca ocurrió, ni siquiera una vez, en más de 1 millón de velas de datos. La navaja de Occam... ¿qué es más probable que haya ocurrido a las 04:29 del 2 de agosto de 1999: que el mercado haya subido 60pips, que la vela haya cerrado en el punto más alto de la vela y que luego, en el siguiente tick que marca el precio de apertura de la siguiente vela, el mercado haya vuelto a bajar 50pips y que la actividad posterior del mercado no haya tenido más volatilidad que las velas que precedieron al pico? ¿O que esta vela en particular contiene un tick espuriosamente malo que puede ser legítimamente (con confianza) eliminado?

Usted notará en el primer gráfico en mi post anterior, para 3+yrs de datos la frecuencia de una brecha de cierre-apertura que excede sólo 4pips para este par es cero. En este caso me sentí cómodo marcando el outlier de 50pip como un obvio outlier y desalojándolo de mi copia del registro histórico de operaciones.

Re: fuentes de confianza frente a la fijación... ya que no se puede confiar en cualquier registro histórico para el precio de venta cuando se utiliza la plataforma MT4 la noción de tener datos históricos confiables frente a los no confiables es realmente una comodidad personal en mi opinión. Depende de su estrategia de comercio específica, por supuesto, en mi caso los detalles exactos del registro histórico son irrelevantes para mi EA. Si una estrategia comercial requiere precisión y exactitud en los registros históricos para que sea rentable, entonces es probable que no sea rentable para las posiciones cortas en cualquier par de divisas, ya que todos los precios de venta se fabrican en el backtesting asumiendo un spread fijo (que no es históricamente preciso o representativo de las condiciones reales del mercado).

Así que si usted va a hacer un EA que es lo suficientemente robusto como para hacer frente a las realidades de los precios de venta que son artificiales en el backtesting, entonces usted probablemente ha creado un EA que es capaz de hacer frente a los datos de precios espurios / erróneos en los registros históricos de todos modos. Podría estar equivocado, no sería la primera vez, pero mi enfoque de los datos históricos es utilizarlos con el propósito de hacer que mi EA sea agnóstico a ellos.

 
1005phillip:


En este caso, con este corredor, un análisis detallado de más de 3 años de datos mostró que tal pico nunca ocurrió, ni siquiera una vez, en más de 1 millón de velas de datos. La navaja de Occam... ¿qué es más probable que haya ocurrido a las 04:29 del 2 de agosto de 1999: que el mercado haya subido 60pips, que la vela haya cerrado en el punto más alto de la vela y que luego, en el siguiente tick que marca el precio de apertura de la siguiente vela, el mercado haya vuelto a bajar 50pips y que la actividad posterior del mercado no haya tenido más volatilidad que las velas que precedieron al pico? ¿O que esta vela en particular contiene un tick espuriosamente malo que puede ser legítimamente (con confianza) eliminado?

Ok, pero este es un caso extremo. Que pasaría si fueran ~30 pips y tuvieras 3 casos así en todos esos años de datos. ¿Cómo se sabe entonces? Mi punto es que habrá casos en los que no es obvio y tienes que adivinar.


Re: fuentes de confianza frente a la fijación... ya que no se puede confiar en cualquier registro histórico para el precio de venta cuando se utiliza la plataforma MT4 la noción misma de tener datos históricos confiables frente a los no confiables es realmente una comodidad personal en mi opinión (...)

Pero ese no es el punto. Estoy hablando de fuentes de confianza que puedes usar tal cual y no pasar por todo este problema. La falta de precio Ask (spread fijo) en MT4 Tester no tiene nada que ver con esto ya que afecta tanto a las fuentes malas, como a las buenas y a las fijas... Es un tema completamente separado.

 

Phillip: En mi opinión, ese es el camino a seguir. Creo que los malos ticks se pueden identificar con bastante seguridad analizando los saltos de precios en combinación con la volatilidad siguiente. Si el mercado muestra un pico y ninguna volatilidad anormal justo en la siguiente barra M1, entonces es un mal tick con una probabilidad muy alta. La captura de pantalla que muestras arriba es un ejemplo de ello.

Ya te has encontrado con la cuestión más importante: definir los malos ticks es una cosa - corregirlos es otra. En mi opinión, hay dos maneras de hacerlo.

1ª: identificar los malos ticks y corregirlos adivinando. Si se trata de la apertura que de repente tiene un gap de +50 pips, entonces regrésalo a digamos +3 pips y así sucesivamente. --> puede no ser preciso pero fácil de implementar
2do: identificar los malos ticks y comparar los precios con otro flujo de datos. Esta sería una forma más precisa - pero mucho más difícil de implementar.

 

Gordon, evito las conjeturas confiando en las propias estadísticas para hacer que los registros históricos sean autoconsistentes. Creo recordar que mencionaste que eras un trader impulsado por las estadísticas fundamentales en otro post, así que entenderás a qué me refiero cuando digo que la premisa es minimizar la divergencia de Kullback-Leibler entre el conjunto de datos sospechosos y el conjunto de datos buenos conocidos (lo que tú etiquetarías como la "fuente confiable").

Sólo en el caso del mercado de divisas utilizaríamos la distribución normal generalizada en lugar de la distribución normal gaussiana, ya que la curtosis de los mercados financieros suele ser mayor que cero. Dudo que te esté diciendo nada nuevo, pero sólo estoy ampliando la premisa de mi metodología para identificar y desalojar los datos sospechosos con confianza (de tipo estadístico, no de tipo machista ;)) para que sepas que mi criterio de selección no es algo tan simplista (y defectuoso) como poner filtros de paso de banda alto/bajo y hacer pasar los datos.

Naturalmente, se hacen suposiciones respecto a la estacionariedad de los datos de precios del instrumento financiero durante el período de tiempo de la "fuente de confianza" cuando se maneja como un proceso estocástico. Pero siempre que esté dispuesto a exigir a mis códigos EA que limiten su actividad a períodos de estacionariedad equivalente en las series temporales futuras, la autoconsistencia es inherente al enfoque. Dado que la duración de los datos de la "fuente de confianza" es finita, se establece un límite superior al período de tiempo en el que podemos esperar que los procesos ciclostacionarios pasados capturados en nuestra caracterización estén representados en las series temporales futuras.

Pero hay un punto de más alto nivel que hay que reforzar aquí y que creo que ambos podemos acordar, y es que, independientemente de la "precisión histórica" de los datos o de la duración en el tiempo representada por los datos, el valor que se obtenga de la utilización de los datos históricos y del backtesting para "optimizar" una estrategia comercial depende totalmente de que la persona sentada detrás del teclado conozca las preguntas a las que hay que responder mediante el backtesting. La cantidad no triunfa sobre la calidad, ni la longitud de los datos históricos ni las horas dedicadas a apisonar una optimización a través del backtesting iterativo responderán a las preguntas que necesitan ser respondidas si la pregunta no estaba bien definida en primer lugar. ¿Cuánto tiempo tardaste en darte cuenta de que "qué parámetros me darán los máximos beneficios o el mínimo drawdown?" NO era la pregunta que había que intentar responder mediante backtesting :)

Schnappi, depende de cuál sea tu objetivo en términos de lo que estás tratando de lograr. ¿Quiere un conjunto de datos que refleje mejor los matices históricos de los precios o está interesado en el número de series temporales en las que se prueban los activadores de las operaciones y la gestión del dinero? No hay una respuesta incorrecta, cada persona aborda las operaciones de mercado de forma diferente, por supuesto. Personalmente, no utilizo datos históricos para probar series temporales lineales, sé que no soy el único, pero reconozco libremente que la mayoría de la gente no lo hace. Utilizo los datos históricos para extraer la naturaleza estadística subyacente a las características de un par de divisas (descomposición de Lévy-Itō) que luego utilizo para crear series temporales estadísticamente equivalentes, pero no idénticas, de datos históricos mediante rutinas de Monte Carlo. A continuación, hago un backtest con estas series temporales hst fabricadas.(esto no es material de lectura ligera pero incluyo el enlace por si no lo conoces y quieres leerlo)

Al igual que la predicción del tiempo, no se pronostica el tiempo de mañana centrándose en conocer los aspectos meteorológicos de hoy y de ayer con un grado de precisión y exactitud cada vez mayor, sino que se crean modelos que capturan las estadísticas inherentes a la evolución de las métricas meteorológicas (temperatura, humedad, presión, etc.) y luego se alteran intencionadamente las condiciones iniciales y se deja que el monte carlo corra hacia adelante en el tiempo, se hace esto unos cuantos miles de veces y se promedian los resultados (en espíritu, los detalles reales son más complicados, naturalmente) y eso formula la base para el pronóstico de mañana "mínimas en la mitad de los 30 y máximas en la parte superior de los 60".

Si te acercas a la idea de filtrar los malos ticks de los datos históricos más antiguos porque simplemente quieres hacer un backtest de 10 años de datos en lugar de 3 años, entonces sólo te advierto que puedes estar cayendo en la falacia de "la cantidad impulsará la calidad" en la que muchos backtesters caen en algún momento de sus carreras. Yo estuve allí una vez, atrapado allí por un tiempo también. Estaba convencido de que mis códigos perdedores se convertirían en ganadores si tuviera más datos históricos para optimizar el backtest. Tal vez resulte ser cierto para algunos y tener ese backtest más largo realmente hace el truco para sus ganancias de pruebas a futuro, pero para mí resultó ser sólo el oro de los tontos (y un montón de tiempo perdido).

Si usted quiere registros históricos más largos porque está empleando funciones de autocorrelación y similares, entonces probablemente esté bien creando su propia serie de datos de precios virtuales/sintéticos para perfeccionar sus cierres y bloqueos de fase, ya que entonces puede controlar directamente la robustez de los protocolos de cierre por medio de la forma en que fabrica las series de tiempo en primer lugar.

No pretendo tener las respuestas correctas, sólo digo que si no empezamos con las preguntas correctas en primer lugar, no podemos esperar que las respuestas sean útiles para nuestro objetivo general (beneficios, presumiblemente).

 
Sí, conozco estos términos, pero sobre todo a nivel teórico. En realidad, mi formación es en Ingeniería de Hardware y hace poco más de un año que me dedico a los algoritmos estadísticos. Mis proyectos actuales se llevan a cabo en colaboración con un par de matemáticos, por lo que la mayor parte del trabajo teórico lo realizan ellos. Estoy seguro de que ellos harían un mejor trabajo discutiendo estos temas contigo :). Sin embargo, es un tema fascinante. Recuerdo que hace unos meses salió el tema de la historia inventada, pero no llegamos a hablar de ello. Todavía estoy probando la historia "real"... (de una fuente "fiable").
 
Phillip: En primer lugar, muchas gracias por estas ideas.
Dices que extraes las características estadísticas de un mercado y luego creas datos de mercado sintetizados y ejecutas simulaciones monte-carlo sobre estos datos. Eso es muy interesante, pero desgraciadamente está más allá de mis habilidades. He empezado a leer los dos enlaces que has puesto pero debo decir que no soy capaz de entenderlos. Tengo una formación universitaria pero no en matemáticas o algo similar. Mi enfoque es un poco más, llamémoslo "práctico", al menos desde el punto de vista de un trader discrecional. Es muy triste. Probablemente no ofrezcan prácticas, ¿no?

Soy consciente de esto que has llamado "la cantidad impulsará la falacia de la calidad" - ya que también he perdido mucho tiempo estando atascado en este punto. Aunque no diría que he perdido este tiempo, pero ese es otro punto. No, la razón por la que entré en esta discusión es que en este momento estoy mejorando mi proceso de desarrollo en sí. Voy a adquirir datos adicionales para aumentar mi alcance. También estamos trabajando en una solución para automatizar los backtests con MT y demás.
 

schnappi Acabo de ver tu post, puedo apreciar el sentimiento y estoy de acuerdo en que al principio todo parece bastante complejo (para estar seguro de que no es simple) pero nunca te permitas sentir que no es algo que no puedes dominar en tus propios términos algún día en el futuro cercano. No necesitas un título universitario para entender y utilizar este material, sólo necesitas el tiempo/la dedicación y el impulso personal para seguir con ello e inevitablemente dominarás los temas.

Es útil conocer algunos de los términos y temas que existen en el sector de las finanzas de inversión profesional, lo que acortará en cierta medida la curva de aprendizaje, y espero que mis publicaciones le hayan ayudado en ese sentido. No estaría donde estoy ahora si no fuera por el hecho de que otros antes que yo ofrecieron sus hombros para que me parara.

Nosotros, los traders cuánticos "caseros", tenemos mucho en común, nuestros orígenes son extremadamente diversos y no muchos de nosotros tenemos educación superior en finanzas o programación, pero lo que nos falta en educación formal lo intentamos compensar con tenacidad y ambición. A Thomas Edison le funcionó... aunque es cierto que no es el mejor ejemplo desde el punto de vista ético y moral, pero su prototipo de 10.000 bombillas es la moraleja de la historia.

Llegarás a reconocer, y quizás ya lo hayas hecho, que tu ritmo de progreso personal es de naturaleza iterativa. Aprendes más sobre las técnicas de codificación y tus códigos se vuelven más sofisticados, aprendes más sobre las estrategias comerciales que han funcionado y no han funcionado en el pasado y perfeccionas tus propias estrategias un poco más, aprendes sobre la gestión del riesgo frente a la medición del riesgo y empiezas a lidiar con tu riesgo de ruina de maneras que ni siquiera eras consciente de que necesitabas en primer lugar.

Y el hecho de que mi enfoque sea aparentemente complejo no significa que la complejidad sea una necesidad... enfoques mucho más simples y mucho menos complejos pueden ser superiores en todos los sentidos... simplemente no soy lo suficientemente inteligente como para haber descubierto cómo. Hay muchas maneras tontamente complejas de hacer una bombilla, y los métodos más complejos no garantizan una bombilla mejor.

Así que no te desanimes por las percepciones que puedas tener entre la complejidad/simplicidad de tu enfoque frente a la falta de ella en el mío... es muy posible que estés en el camino correcto mientras que yo estoy en el campo de la izquierda.

 

1005phillip: 2010.03.17 18:38

Esto(script mq4 adjunto) es lo que uso para hacer el trabajo, no es bonito (el código que es) y podría hacer con un poco de limpieza y el cambio de la repetitiva si para los interruptores, etc.

Nota: Las horas de apertura de las velas W1 se alinean automáticamente con el primer día de la semana comercial (lunes) y las horas de apertura de las velas MN se alinean automáticamente con el primer día de mercado abierto del nuevo mes.
Este script está roto. El primer día de la semana comercial es el domingo (2200z) no el lunes. Y no maneja los días festivos del viernes o del lunes. Solución simple:
      time0=Time[i];
//    if((TimeDayOfWeek(time0)==1 && TimeDayOfWeek(Time[i+1])==5) || i==0)
      if (TimeDayOfWeek(time0) < TimeDayOfWeek(Time[i+1])         || i==0)