Eu preciso de um bom arquivo de história para EURUSd - página 4

 

schnappi, naturalmente a metodologia para identificar (e eventualmente remediar) carrapatos e buracos de dados ruins é em si um processo em evolução. Comecei com a abordagem padrão de filtros definidos externamente (se delta de preço > X então temos um tique ruim, etc.) e o problema com isso é que você força o conjunto de dados a se adequar às suas percepções e expectativas de como devem ser os dados de preço que podem ou não ser representativos das características estatísticas intrínsecas da dinâmica de evolução de preços do instrumento financeiro.

Eventualmente, meu método foi iterado ao ponto de simplesmente exigir que os dados sejam autoconsistentes com as características intrínsecas do próprio instrumento financeiro (par de moedas nesta discussão, mas se aplica a todos os níveis). O que isto significa na prática é que tomo um trecho de "bons dados de mercado conhecidos" e caracterizo de forma robusta seus atributos: lacunas de tempo, lacunas de preço, etc. Isto gera um perfil de evolução de preços naturais/característicos para o par de moedas (que será específico para cada corretor, pois cada corretor tem seus próprios algoritmos sutis de "bomba e pulso" para manter a alimentação de preços "viva").

Armado com estes dados de caracterização, tenho então o script iterar através dos períodos de tempo mais antigos, mais questionáveis, avaliando cada barra com base nos méritos de se ela é estatisticamente consistente com a natureza inerente do par de moedas. Por exemplo, digamos que observemos que a diferença de preço que ocorre entre as sucessivas velas M1 para o USDJPY é geralmente <3pips. Isto quer dizer que a oferta fechada para a vela N+1 está geralmente a qualquer distância de -3 a +3 pips da oferta de abertura da vela N.

Esta é uma métrica fácil de gerar as estatísticas para, basta analisar o close(i+1)-open(i) para seus dados e gerar um histograma: (nota eu especificamente/intencionalmente excluo as lacunas de preço que vêm dos pares de velas que eles mesmos têm uma lacuna de tempo entre eles para esta fase da caracterização)


Agora, se você avaliar os dados históricos de algum ano anterior, digamos 2003, e seu script observar uma diferença de preço entre velas sucessivas (sem intervalo de tempo) que está bem fora da faixa estatisticamente consistente (para este exemplo, digamos que é detectada uma diferença de 50pip), então seu script tem motivos para considerar os dados de preço sob avaliação naquele momento como suspeitos.

O que você faz com suas velas suspeitas (a fase de remediação) é toda uma outra questão, mas aqui está um exemplo:


Há perigos e armadilhas a serem evitados na remediação de dados, você pode desconhecidamente causar mais danos do que benefícios se não tiver cuidado em como definir sua lista de despejo de velas ruins assim como suas substituições (considero simplesmente apagar a vela do registro hst como uma política de substituição também, substituindo uma falha de preço ruim por uma falha de tempo artificial nesse caso).

 
Phillip, isso é algo interessante, mas me parece muito arriscado e demorado. Prefiro usar fontes em que posso confiar do que tentar 'consertar' fontes que não posso...

Em relação a essas velas "suspeitas". Muitos corretores têm picos de preços estranhos por várias razões. Em seu exemplo acima, como você sabe que se trata de um dado óbvio de "mau tique"? Espigões como esses acontecem...
 
gordon wrote >>
Phillip, isso é algo interessante, mas me parece muito arriscado e demorado. Prefiro usar fontes em que posso confiar do que tentar 'consertar' fontes que não posso...

Em relação a essas velas "suspeitas". Muitos corretores têm picos de preços estranhos por várias razões. Em seu exemplo acima, como você sabe que se trata de um dado óbvio de "mau tique"? Espigões como esses acontecem...


Re: como você sabe que se trata de um dado óbvio de "bad tick"... neste caso com este corretor, uma análise detalhada de 3+ anos de dados mostrou que tal pico nunca ocorreu, nem mesmo uma vez, em mais de 1 milhão de velas de dados. O que é mais provável que tenha ocorrido às 04:29 de agosto de 1999: o mercado subiu 60pips, a vela fechou no alto da vela e, em seguida, o próximo tick marcando o preço de abertura da próxima vela, o mercado desceu 50pips e a atividade subseqüente do mercado não teve mais volatilidade do que as velas que antecederam o pico? Ou que esta vela em particular contém um carrapato espantosamente ruim que pode ser legitimamente eliminado (com confiança)?

Você notará pelo primeiro gráfico no meu post acima, para mais de 3 anos de dados, a freqüência de uma abertura próxima a 4pips que exceda apenas 4pips para este par é zero. Neste caso, eu me senti à vontade para marcar o outlier de 50pips como sendo um outlier óbvio e expulsá-lo de minha cópia do histórico de negociação.

Re: fontes confiáveis versus fixação... já que você não pode confiar em nenhum registro histórico pelo preço pedido ao usar a plataforma MT4, a própria noção de ter dados históricos confiáveis versus não confiáveis é realmente um conforto pessoal na minha opinião. Depende de sua estratégia comercial específica, é claro, no meu caso as especificidades exatas do registro histórico são irrelevantes para a minha EA. Se uma estratégia comercial requer precisão e exatidão nos registros históricos para que seja lucrativa, então provavelmente não será lucrativa para posições curtas em qualquer par de moedas, já que todos os preços pedidos são fabricados em retrocesso, assumindo um spread fixo (que não é historicamente preciso ou representativo das condições reais do mercado).

Portanto, se você vai fazer um EA que seja robusto o suficiente para lidar com a realidade de que os preços de venda são obtidos em backtesting, então você provavelmente criou um EA que é capaz de lidar com dados de preços espúrios/errosos em registros históricos de qualquer forma. Eu poderia estar errado, não seria a primeira vez, mas minha abordagem aos dados históricos é usá-los com o propósito de tornar minha EA agnóstica a eles.

 
1005phillip:


Re: como você sabe que se trata de um dado óbvio de "bad tick"... neste caso com este corretor, uma análise detalhada de 3+ anos de dados mostrou que tal pico nunca ocorreu, nem mesmo uma vez, em mais de 1 milhão de velas de dados. O que é mais provável que tenha ocorrido às 04:29 de agosto de 1999: o mercado subiu 60pips, a vela fechou no alto da vela e, em seguida, o próximo tick marcando o preço de abertura da próxima vela, o mercado desceu 50pips e a atividade subseqüente do mercado não teve mais volatilidade do que as velas que antecederam o pico? Ou que esta vela em particular contém um carrapato espantosamente ruim que pode ser legitimamente eliminado (com confiança)?

Ok, mas este é um caso extremo. E se fosse ~30 pips e você tivesse 3 casos desses em todos esses anos de dados. Como você sabe então? O meu ponto é que haverá casos onde não é óbvio e você tem que adivinhar.


Re: fontes confiáveis versus fixação... já que você não pode confiar em nenhum registro histórico pelo preço pedido ao usar a plataforma MT4 a própria noção de ter dados históricos confiáveis versus dados históricos não confiáveis é realmente um conforto pessoal na minha opinião (...)

Mas não é essa a questão. Estou falando de fontes confiáveis que você pode simplesmente usar como está e não passar por todo esse trabalho. A falta de preço Ask (spread fixo) no MT4 Tester não tem nada a ver com isso, pois afeta tanto as fontes ruins, como as boas fontes e as fontes fixas... É uma questão completamente à parte.

 

Phillip: Na minha opinião, esse é o caminho a seguir. Acho que os carrapatos ruins podem ser identificados com bastante segurança analisando os saltos de preços em combinação com a seguinte volatilidade. Se o mercado mostra um pico e nenhuma volatilidade anormal logo na próxima barra M1, então é um mau carrapato por muito alto risco. A captura de tela que você está mostrando acima é um exemplo disso.

Você já se deparou com a questão mais importante: definir carrapatos ruins é uma coisa - corrigi-los é outra. Na minha opinião, há duas maneiras de fazer isso.

Primeira: identificar carrapatos maus e corrigi-los adivinhando. Se é o aberto que, de repente, abre +50 pips, então retorne para dizer +3 pips e assim por diante. --> pode não ser preciso, mas fácil de implementar
2º: identificar carrapatos ruins e comparar os preços com outro fluxo de dados. Esta seria uma maneira mais precisa - mas muito mais difícil de implementar.

 

Gordon, eu evito adivinhar confiando nas próprias estatísticas para fazer com que os registros históricos sejam autoconsistentes. Acho que me lembro de você ter mencionado que foi um negociante fundamental para as estatísticas em outro posto, então você entenderá o que estou falando quando digo que a premissa é minimizar a divergência Kullback-Leibler entre o conjunto de dados suspeito e o conhecido bom conjunto de dados (o que você rotularia como a "fonte confiável").

Somente no caso do forex usaríamos a distribuição normal generalizada em vez das distribuições gaussianas normais, já que a curtose dos mercados financeiros é tipicamente maior que zero. Duvido que esteja dizendo algo novo para vocês, mas estou apenas expandindo a premissa de minha metodologia para identificar e despejar dados suspeitos com confiança (do tipo estatístico, não do tipo machismo;)) para que vocês saibam que meu critério de seleção não é algo tão simplista (e falho) quanto definir filtros passa-banda alto/baixo e passar os dados.

Naturalmente, há suposições feitas com relação à estacionaridade dos dados de preços do instrumento financeiro ao longo do período de tempo da "fonte confiável" ao tratá-los como um processo estocástico. Mas desde que eu esteja disposto a exigir que meus códigos EA confinem sua atividade a períodos de estacionaridade equivalentes em séries temporais futuras, então a autoconsistência é inerente à abordagem. Como a duração dos dados da "fonte confiável" é finita, ela estabelece um limite superior para o período de tempo no qual podemos esperar que processos cíclicos passados capturados em nossa caracterização sejam representados em séries temporais futuras.

Mas há um ponto de nível superior a ser reforçado aqui que eu acho que ambos podemos concordar que, independentemente da "precisão histórica" dos dados ou da duração no tempo representada pelos dados, o valor a vir do uso de dados históricos e de backtesting para "otimizar" uma estratégia comercial depende inteiramente da pessoa sentada atrás do teclado saber as perguntas que precisam ser respondidas por backtesting. A quantidade não é um trunfo para a qualidade, nem a duração dos dados históricos nem as horas gastas com uma otimização através de testes iterativos de retrocesso responderão às perguntas que precisam ser respondidas se a pergunta não foi bem definida em primeiro lugar. Quanto tempo você levou para perceber que "quais parâmetros me darão o máximo de lucro ou o mínimo de drawdown?" NÃO foi a pergunta a ser tentada e respondida através de backtesting :)

Schnappi, depende de qual é seu objetivo em termos do que você está tentando alcançar. Você quer um conjunto de dados que reflita ainda mais as nuances de preços historicamente precisos ou está interessado no número de séries temporais que seus gatilhos comerciais e gestão de dinheiro são testados? Não há uma resposta errada, todos abordam o comércio de mercado de maneira diferente, é claro. Pessoalmente eu não uso dados históricos para testes de séries temporais lineares, sei que não estou sozinho nisto, mas reconheço livremente que a maioria das pessoas não o faz. Utilizo dados históricos para extrair a natureza estatística bruta subjacente às características de um par de moedas (decomposição Lévy-Itō) que depois utilizo para criar séries temporais de dados históricos estatisticamente equivalentes, mas não idênticas, por meio de rotinas de monte carlo. Em seguida, faço um backtest com estas séries temporais fabricadas.(isto não é material de leitura leve, mas incluo o link por acaso você ainda não está ciente e queria ler sobre ele)

Assim como a previsão do tempo, você não prevê o tempo de amanhã, concentrando-se em conhecer os aspectos do tempo de hoje e de ontem com graus cada vez maiores de precisão e exatidão, mas sim cria modelos que capturam as estatísticas inerentes à evolução da métrica do tempo (temperatura, umidade, pressão, etc.) e depois altera intencionalmente as condições iniciais e deixa o monte carlo avançar no tempo, você faz isso algumas milhares de vezes e calcula a média dos resultados (em espírito, os detalhes reais são mais complicados naturalmente) e isso formula a base para a previsão de amanhã".baixas em meados da década de 30 e altas na década de 60".

Se você está se aproximando da idéia de filtrar carrapatos ruins de dados históricos mais antigos porque você simplesmente quer fazer um backtest de 10 anos em vez de 3 anos, então eu vou apenas adverti-lo de que você pode estar caindo na falácia "a quantidade vai impulsionar a qualidade" pela qual muitos backtesters caem em algum momento de suas carreiras. Eu estive lá uma vez, preso lá também por um tempo. Estava convencido de que meus códigos perdidos se tornariam vencedores se eu tivesse dados históricos mais longos para otimizar o backtest. Talvez seja verdade para alguns e o fato de ter um backtest mais longo realmente faz o truque para seus lucros nos testes de avanço, mas para mim acabou sendo apenas o ouro dos tolos (e muito tempo desperdiçado).

Se você está querendo registros históricos mais longos porque está empregando funções de autocorrelação e coisas do gênero, então provavelmente está tão bem quanto criar sua própria série de dados de preços virtuais/sintéticos para afiar suas travas e travas de fase quanto então você pode controlar diretamente a robustez dos protocolos de trava através da forma como você fabrica as séries de tempo em primeiro lugar.

Não pretendo ter as respostas certas, apenas dizendo que se não começarmos com as perguntas certas em primeiro lugar, então não podemos esperar que as respostas sejam de qualquer utilidade para nosso objetivo geral (lucros, presumivelmente).

 
Sim, eu conheço estes termos, mas principalmente a nível teórico. Minha formação é na verdade em Engenharia de Hardware e só tenho lidado com algoritmos estatísticos há pouco mais de um ano. Meus projetos atuais são feitos em conjunto com um par de matemáticos, portanto a maior parte do trabalho teórico é feita por eles. Tenho certeza de que eles fariam um trabalho melhor ao discutir estes assuntos com vocês :). Coisas fascinantes, porém. Lembro-me do assunto da história fabricada que surgiu há alguns meses, mas nunca chegamos a ele. Ainda testando a história 'real'... (de uma fonte 'confiável').
 
Phillip: Antes de mais nada, muito obrigado por estas idéias.
Você está dizendo que você extrai as características estatísticas de um mercado e depois cria dados de mercado sintetizados e executa simulações monte-carlo sobre estes dados. Isso é extremamente interessante, mas infelizmente isso está além das minhas habilidades. Comecei a ler os dois links que você postou, mas devo dizer que não sou capaz de entendê-los. Eu tenho formação universitária, mas não em matemática ou algo semelhante. Minha abordagem é um pouco mais, vamos chamá-la de "prática" - pelo menos do ponto de vista de um comerciante discreto. Realmente triste. Vocês provavelmente não oferecem estágios, não é mesmo?

Estou ciente disso que você chamou de "a quantidade vai impulsionar a queda de qualidade" - já que também já perdi muito tempo ficando preso neste ponto. Embora eu não diria que teria desperdiçado este tempo, mas esse é um ponto diferente. Não, a razão pela qual eu entrei nesta discussão é que no momento estou aprimorando meu próprio processo de desenvolvimento. Vou adquirir dados adicionais para aumentar meu escopo. Também estamos trabalhando em uma solução para automatizar os backtests com a MT e assim por diante.
 

schnappi que acabei de ver seu posto, posso apreciar o sentimento e concordo que a princípio tudo parece bastante complexo (para ter certeza de que não é simples), mas nunca se deixe sentir que não é algo que você não possa dominar em seus próprios termos um dia, num futuro próximo. Você não precisa de um diploma universitário para entender e usar este material, você só precisa de tempo/dedicação e vontade pessoal para se manter e, inevitavelmente, dominará os tópicos.

Isso ajuda a tomar consciência de alguns dos termos e tópicos que existem no setor de financiamento de investimentos profissionais existentes, que irão longe para encurtar a curva de aprendizado, e espero que meus cargos o tenham ajudado nessa capacidade. Eu não estaria onde estou agora se não fosse pelo fato de que outros antes de mim ofereceram seus ombros para eu ficar de pé.

Nós, os comerciantes quânticos "criados em casa", todos temos muito em comum, nossas origens são extremamente diversas e não muitos de nós temos educação superior em finanças ou programação, mas o que nos falta em educação formal, pretendemos compensar com tenacidade e ambição. Funcionou para Thomas Edison... admito que não é o melhor exemplo do ponto de vista ético/moral, mas seu protótipo de 10.000 lâmpadas é o exemplo moral da história.

Você chegará a reconhecer, e talvez já tenha reconhecido, que seu ritmo pessoal de progresso é iterativo por natureza. Você aprende mais sobre técnicas de codificação e seus códigos se tornam mais sofisticados, você aprende mais sobre estratégias comerciais que funcionaram e não funcionaram no passado e você afina um pouco mais suas próprias estratégias, você aprende sobre gestão de risco versus medição de risco e você começa a lidar com seu risco de ruína de maneiras que você nem mesmo sabia que precisava em primeiro lugar.

E só porque minha abordagem é aparentemente complexa, não significa que a complexidade seja uma neccessidade... abordagens muito mais simples e muito menos complexas podem ser superiores em todos os sentidos... Eu simplesmente não sou suficientemente inteligente para ter descoberto como ainda. Há muitas maneiras insensatamente complexas de fazer uma lâmpada, e métodos mais complexos não garantem uma lâmpada melhor.

Por isso, não se deixe levar por nenhuma percepção que você possa ter entre a complexidade/simplicidade de sua abordagem e a falta dela na minha... você pode muito bem estar no caminho certo enquanto eu estiver fora no campo da esquerda.

 

1005phillip: 2010.03.17 18:38

Isto(script mq4 anexo) é o que eu uso para fazer o trabalho, não é bonito (o código que é) e poderia fazer com algumas limpezas e mudanças repetitivas, se for para interruptores, etc.

Nota: Os tempos de abertura das velas W1 são automaticamente alinhados ao primeiro dia da semana comercial (segunda-feira) e os tempos de abertura das velas MN são automaticamente alinhados ao primeiro dia de mercado aberto do novo mês.
Este roteiro está quebrado. O primeiro dia da semana comercial é domingo (2200z) e não segunda-feira. E não trata de feriados às sextas-feiras ou segundas-feiras. Simples conserto:
      time0=Time[i];
//    if((TimeDayOfWeek(time0)==1 && TimeDayOfWeek(Time[i+1])==5) || i==0)
      if (TimeDayOfWeek(time0) < TimeDayOfWeek(Time[i+1])         || i==0)